3.5 面向连接的运输：TCP

3.5.1 TCP连接

TCP进行传输之间要进行三次握手建立连接，这个连接不是物理意义上的有一根电线连接，而是应用端两个应用，在逻辑上是已经建立连接了。

TCP 不需要传输的时候会进行四次挥手断开连接。

持续连接：在传输过程中一直保持连接，直到没有数据可以传输。

非持续连接：指传输完一组数据就断开连接，在传输就要建立新的连接。

3.5.2 TCP报文段结构

源端口号								目的端口号
序号
确认号
首部长度	保留未用	URG	ACK	PSH	RST	SYN	FIN	接收窗口
因特网检验和								紧急数据指针
选项
数据

源端口号，目的端口号：略

序号：就是第一个字节的序号，例如总共1000位，成2个报文段，第一个报文段序号是0，第二个报文段序号是500

确认号：表示N之前的字段全部接收到了

首部长度：4比特，通常首部长度20个字节。20 * 8bit，本来应该是24个字节，但是选项字段一般为空，所以就是20个字节。

URG：标记是否紧急

ACK：确认bit

PSH：被标记，表示接收方应该立即提交给上层数据

RST，SYN，FIN：用于连接的创建和拆除，RST表示连接重置，SYN表示建立连接，FIN表示关闭连接

接收窗口：用于流量控制，表示接收方愿意接受的字节数量

因特网检验和：用于差错检验

紧急数据指针：指出紧急数据的最后一个字节

3.5.4 可靠数据传输

TCP在IP不可靠的尽力而为服务商创建里一种可靠数据传输服务。

TCP保证从接收缓存中都取出来的数据都是无损坏，无间隔，非冗余，按序的数据流。

一些有趣的情况

第一种情况：

A的报文段序号是92，向B发送了8个字节，那么B应该向A传输ACK（100）表示100以前的报文段收到了，但是B的确认报文丢了，那么A就以为B没收到，所以A就又重现发送了一边数据，造成了数据冗余。

第二种情况：

A连续发送两个报文段给B，第一个报文段序号是92，发送了8个字节，第二个报文段序号是100，发送了20个字节，都完好无损的到达了B，那么第一个报文段的确认号应该是100，第二个应该是120，假设两个回传的确认报文都超时了，A就以为B没收到，所以重传，当A重传序号92的报文段并重启定时器，此时第二个报文（120）的确认报文到了，那么第二个报文就不会被重传。

第三种情况：

和第二种情况一样，在准备重传的时候，第二个报文的确认报文到了，那么两个报文都不会被重传。

超时间隔加倍

实际上就是超时之后，扩大了确认超时的限制。

快速重传

像前面说到的，如果等不到确认报文才开始准备重传，这样会大大增加时延。

快速重传采取的判断丢包的措施是：

如果接收方收到三个冗余ACK（N）即判断丢包了，就立即重传第一个没被确认的报文。

原因：假设A向B发送 n – 1, n, n + 1, n + 2，并且已经收到n – 1

不丢包的情况：

B接收报文的顺序有以下可能：

　　　n – 1, n, n + 1, n + 2;

　　 A收到1次ACK（n）；

　　 n – 1, n, n + 1, n + 2;

　　 A收到1次ACK（n）；

　　 n – 1, n + 1, n, n + 2

　　 A收到两次ACK（n）；

　　 n – 1, n + 1, n + 2, n

　　 A收到三次ACK（n）；

　　 n – 1, n + 2, n, n + 1

　　 A收到两次ACK（n）；

　　 n – 1, n + 2, n + 1, n

　　 A收到三次ACK（n）;

抛去第一种按序到达，乱序到达并且收到3次ACK（n）的概率是2 / 5 = 40%

然后是丢包的情况：

不管什么顺序到达，都会收到3次ACK（n），概率是100%；

虽然收到三次ACK（n）不一定是丢包造成的，但是丢包一定会收到三次ACK（n），两次可能是乱序造成的，三次可能是丢包造成的，四次更可能是丢包造成的但是时延太多，所以就取三次。

是回退N步（GBK）还是选择重传（SR）：

TCP作为GBK和SR的混合体，视情况选择两种协议

3.5.5流量控制

接收方维护一个接收窗口（rwnd）的变量来提供流量控制。

假设A通过一条TCP连接，向B发送一个大文件，那么B会为此次连接分配一个缓存，用RcvBuffer表示。

定义两个变量：

LastByteRead：表示应用程序从缓存中读取的最后一个字节的编号

LastByteRcvd：表示接收到数据的最后一个编号

灰色：表示已经读取的部分

深灰色：表示已经缓存，但是没有读取的元素

那么LastByteRead就是A所在的位置，LastByteRcvd就是B所在的位置。

由于TCP不允许缓存溢出，所以LastByteRcvd – LastByteRead <= RcvBuffer。接收窗口那么就只能接收剩余空间了，rwnd <= RcvBuffer – (LastByteRcvd – LastByteRead)。

因此rwnd是进行动态维护的。

还有一个小问题：

假设B的缓存已经满了，即rwnd = 0，所以B的应用程序要清空缓存，但是A并

不知道B有了新的缓存了，所以不会再发送数据，就造成了拥塞。为了解决这个问题，

TCP规范中要求：当主机B接收窗口为0的时候，主机A继续发送一个只含1个字节的报文段，这个字节被B接收，并清空缓存。

UDP是不提供流量控制的，UDP通常将数据添加到相应套接字“前面”的一个有限大小的缓存中，如果进程读取的不够快，那么缓存就会溢出，并且将丢失报文段。

3.5.6TCP连接

三次握手建立连接：

A想向B传输可靠数据，所以要向B建立一条TCP连接。

A向B发送一个特殊的TCP报文，SYN字段被置1表示要建立连接，称为SYN报文段，然后随机选择一个初始序列号（client_isn），放在SYN报文段的序号字段中。封装到IP数据报中，并发送给B。
B收到来自A的SYN报文段，为TCP分配缓存和变量，并向A发送SYN报文，确认号为client_isn + 1 ，并且随机选择一个初始序列号（server_isn）放到SYN报文段的序列号字段。

注意前两次报文都是不携带应用数据的。

　　 3. A收到B的确认报文（，此时已经建立连接），A为TCP分配缓存和变量，然后再给B发送一个报文，SYN标志位置0，确认字段为server_isn + 1。

客户端TCP状态序列：

初始TCP客户端处于CLOSED状态。

打开连接：

　　 ①：客户的应用程序发起一个新的TCP连接，引起客户中的TCP向服务器中的TCP发送一个SYN报文段，然后客户端进入SYN_SENT状态

②：收到服务器发来的ACK确认报文段之后进入ESTABLISHED状态（建立连接），此时TCP客户就能发送和接受包含有效载荷数据的TCP报文段了

关闭连接：

③：客户端TCP发送一个带有FIN标置为1的报文段，客户端进入FIN_WAIT_1状态。

④：客户端收到服务器发送的ACK确认报文段，客户端进入FIN_WAIT_2状态。

⑤：当客户端处于FIN_WAIT_2状态时，客户端等待服务器发送的FIN报文段，收到FIN报文段，确认后，并进入TIME_WAIT。

⑥：如果ACK报文丢失，那么TIME_WAIT状态会使TCP客户端重传最后的确认报文段

最后连接正式关闭，客户端所有资源被释放。

为什么要三次握手，两次已经建立连接了，为什么还要第三次？

谢仁希《计算机网络》看到的，为了防止已经失效的连接请求报文突然传到服务端造成错误，例如一个第一次握手的报文因为拥塞或者各种原因超时了，即发送端发送了另外的请求报文，那么超时的这个报文就失效了，如果这个报文又传到了服务端，如果只经过两次握手的话，那么就可以建立连接，但是这个连接是不需要的，所以就造成了浪费。

四次挥手释放连接：

首先发送方给接收方发送报文并且FIN置1。
当接收方收到报文，返回ACK确认报文。
接收方再发送一个报文FIN置1
接收方收到发送方的ACK确认报文
用于此次连接的所有资源被释放

服务器端TCO状态序列：

建立连接：

① ：服务器应用程序创建一个监听套接字，进入LISTEN状态

② ：接收SYN并且发送SYN&ACK进入SYN_RVCD的状态

③ ：接收ACK，等待发送方的数据，进入ESTABLISHED状态

释放链接：

④ ：接收FIN发送ACK，进入CLOSE_WAIT状态

⑤ ：发送FIN，进入LAST_ACK状态

⑥ ：接收ACK不发送，关闭连接

为什么进行四次挥手？

TCP是双工通信，一方收到FIN报文的时候，只是说明没有接收的报文了，还是可以发送的，一方发送了FIN报文，处于FIN_wait1状态，但收到对方确认的ACK报文的时候进入FIN_wait2状态，此时处于半断开。因为是双工通信，所以可能一方想断开，但是另一方还有数据要传输，要等一会在断开，所以进行四次挥手。