『网络』浅谈TCP协议

TCP概述

UDP是一个简单的协议，它有一些非常重要的用途，比如客户端-服务器交互和多媒体应用，但是对于大多数Internet应用来说，它们需要可靠的、按序递交的传输特性。UDP不能提供这样的功能，所以Internet还需要另一个协议，这就是TCP，它是Internet的主力军。
传输控制协议（TCP，Transmission Control Protocol）是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。互联网络与单个网络有很大的不同，因为互联网络的不同部分可能有截然不同的拓扑结构、带宽、延迟、数据包大小和其他参数。TCP的设计目标识能够动态地适应互联网络的这些特性，而且具备面对各种故障时的健壮性。

TCP首部

• 源/目的端口号：标识数据从哪来到哪去。
• 32位序号/确认序号：
• 4位TCP报头长度：标识该TCP头部有多少个32位bit（有多少个4字节）；所以TCP头部最大长度是15 * 4 = 60。
• 6位标志位。
  URG：紧急指针是否有效（当前序号到紧急指针所指向的位置之间的数据为紧急数据（需要优先交付给应用层））。
  ACK：确认号是否有效。
  PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走。
  RST：对方要求重新建立连接；我们把携带RST标识的称为复位报文段。
  SYN：请求建立连接；我们把携带SYN标识的称为同步报文段。
  FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段。
• 16位窗口大小：
• 16位校验和：发送端填充，CRC校验。接收端校验不通过，则认为数据有问题。此处的校验和不光包含TCP首部，也包含TCP数据部分。
• 16位紧急指针：标识哪部分数据是紧急数据。
• 40字节头部选项：

TCP特点

• 面向连接：通信之前先建立连接，确保双方在线。
• 可靠传输：在网络正常的情况下，数据不会丢失。
• 面向字节流：传输灵活，但是数据之间没有明显边界，存在粘包问题。

确认应答机制

• TCP将每个字节的数据都进行了编号，即为序列号。
  
• 每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据；下一次你从哪里开始发。
  

超时重传机制

• 主机A发送数据给B之后，可能因为网络堵塞等原因，数据无法到达主机B。
• 如果主机A在一个特定的时间间隔内没有收到B发来的确认应答，就会进行重发。
  
• 但是，主机A未收到B发来的确认应答，也可能是ACK丢失了。
  

因此主机B会收到很多重复的数据。那么TCP协议需要能够识别出哪些包时重复的包，并且把重复的包丢掉。这时候我们可以利用前面提到的序列号，就可以很容易做到去重的效果。
那么，超时的时间如何确定？

• 最理想的情况下，找到一个最小的时间，保证“确认应答一定能再这个时间内返回”。
• 但是这个时间的长短，随着网络环境的不同，是有差异的。
• 如果超时时间设的太长，会影响整体的重传效率。
• 如果超时时间设的太短，有可能会频繁发送重复的包。

TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。

• Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。
• 如果重发一次之后，仍然得不到应答，等待2 * 500ms后再进行重传。
• 如果仍然得不到应答，等待4 * 500ms进行重传。依次类推，以指数形式递增。
• 累积到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。

连接管理机制

• 在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接。
  

服务端状态转化：

• [CLOSED -> LISTEN]服务器调用listen后进入LISTEN状态，等待客户端连接。
• [LISTEN -> SYN_RCVD]一旦监听到连接请求（同步报文段），就将该连接放入内核等待队列中，并向客户端发送SYN确认报文。
• [SYN_RCVD -> ESTABLISHED]服务端一段收到客户端的确认报文，就进入ESTABLISHED状态，可以进行读写数据了。
• [ESTABLISHED -> CLOSE_WAIT]当客户端主动关闭连接（调用close），服务端会受到结束报文段，服务器返回确认报文段并进入CLOSE_WAIT。
• [COSE_WAIT -> LAST_ACK]进入CLOSE_WAIT后说明服务器准备关闭连接（需要处理完之前的数据）；当服务器真正调用close关闭连接时，会像客户端发送FIN，此时服务器进入LAST_ACK状态，等待最后一个ACK到来（这个ACK是客户端确认收到了FIN）。
• [LAST_ACK -> CLOSED]服务器收到了对FIN的ACK，彻底关闭连接。

客户端状态转化：

• [CLOSED -> SYN_SENT]客户端调用connect，发送同步报文段。
• [SYN_SENT -> ESTABLISHED]connect调用成功，则进入ESTABLISHED状态，开始读写数据。
• [ESTABLISHED -> FIN_WAIT_1]客户端主动调用close时，向服务器发送结束报文段，同时进入FIN_WAIT_1。
• [FIN_WAIT_1 -> FIN_WAIT_2]客户端收到服务器对结束报文段的确认，则进入FIN_WAIT_2，开始等待服务器的结束报文段。
• [FIN_WAIT_2 -> TIME_WAIT]客户端收到服务器发来的结束报文段，进入TIME_WAIT，并发出LAST_ACK。
• [TIME_WIAIT -> CLOSED]客户端要等待一个2MSL（Max Segment Life，报文最大生存时间）的时间，才会进入CLOSED状态。

TIME_WAIT状态

这里，我们做一个测试，还是使用前面写的httpserver程序，启动该程序，然后ctrl + C使程序终止，这时马上再运行httpserver程序。

结果如上，这是因为，虽然httpserver的应用程序虽然终止了，但是TCP协议层的连接并没有完全断开，因此不能再次监听同样的端口。
我们使用netstat命令查看一下：

从上可以看到端口9999处于TIME_WAIT状态。

• TCP协议规定，主动关闭连接的一方要处于TIME_WAIT状态，等待两个MSL（maximum segmeng lifetime）的时间后才能回到CLOSED状态。
• 我们使用ctrl + c终止了httpserver，所以httpserver是主动关闭连接的一方，在TIME_WAIT期间仍然不能再次监听同样的端口。
• MSL在RFC1122中规定为两分钟，但是各操作系统的实现不同，在Centos7上默认配置的值是60s。
• 可以通过命令cat /proc/sys/net/ipv4/tcp_fin_timeout查看MSL的值。
  

为什么TIME_WAIT的时间是2MSL时间？

• 虽然按道理说，四个报文发送完毕，就可以进入CLOSE状态了，但是网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在客户端发出最后的ACK回复，但是该ACK可能丢失。服务端如果没有收到ACK，将不断重复发送FIN片段。所以客户端不能立即关闭，它必须确认服务端收到了该ACK。
• 客户端在发送出ACK之后进入TIME_WAIT状态，客户端回设置一个计时器，等待2MSL时间，如果在该时间内再次收到FIN，那么客户端会重发ACK并再次等待2MSL时间。
• 所谓的2MSL是2倍的MSL（Max Segment Lifetime，最大报文生存时间）。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，客户端都没有再次收到FIN，那么客户端推断ACK已经被成功接收。则结束TCP连接。

如何解决TIME_WAIT状态引起的bind失败的方法

一般都是服务端出现TIME_WAIT状态，客户端一般不会出现这个问题，因为客户端没有手动绑定端口号。
在server的TCP连接还没有完全断开之前不允许重新监听，某些情况下可能是不合理的：

• 服务器需要处理非常大量的客户端的连接（每个连接的生存时间可能很短，但是每秒都有很大数量的客户端来请求）。
• 这个时候如果由服务器主动关闭连接（比如某些客户端不活跃，就需要被服务端主动清理掉），就会产生大量TIME_WAIT连接。
• 由于我们的请求量很大，就可能导致TIME_WAIT的连接数很多，每个连接都会占用一个通信五元组（源IP、源端口、目的IP、目的端口、协议）。其中服务器的IP、端口号和协议是固定的。如果新来的客户端连接的IP、端口号和TIME_WAIT占用的连接重复了，就会出现问题。

解决方法：

使用setsockopt()接口

int setsockopt(int sockfd, int level, int optname,
				const void *optval, socklen_t optlen);
参数：
	sockfd：套接字描述符。
	level：选项定义的层次。
		   支持SOL_SOCKET、IPPROTO_TCP、IPPROTO_IP和IPPROTO_IPV6。
	optname：需设置的选项。
		SO_REUSEADDR为1，表示允许创建端口号相同但IP地址不同的多个socket描述符。
	optval：指针，指向存放选项带设置的新值的缓冲区。
	optlen：optval缓冲区长度。
返回值：若无错误发生，setsockopt()返回0。否则的话，返回SOCKET_ERROR错误，应用程序可通过WSAGetLastError()获取相应错误代码。

使用方法如下：

• 在tcp_socket头文件中的TcpSocket类中新增成员函数SetSockOpt()。
  
• httpserver中程序进行相应调整，在服务端套接字创建完成后，调用上述接口。
  
• 效果如下：
  

修改MSL时间

[root@aliyun sss]# vim /proc/sys/net/ipv4/tcp_fin_timeout

将MSL的时间设置的小一点。

滑动窗口

• 前面讨论的确认应答机制，对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。还有因为ACK丢失导致的数据重传很不划算。
  
• 既然这样收一发一的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能（其实是将多个段的等待时间重叠在一起）。
  
• 窗口大小指的是无序等待确认应答而可以继续发送数据的最大值。上图中的窗口大小就是500字节（五个段）。
• 发送前五个段的时候，不需要等待任何ACK，直接发送。
• 收到第一个ACK后，滑动窗口向后移动，继续发送第六个段的数据；依次类推。
• 操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉。
• 窗口越大，网络的吞吐率就越高。
  

那么如果出现了丢包，如何进行重传？分两种情况：

• 情况一：数据报已经抵达，ACK被丢了。
  
  这种情况，部分ACK丢了并不要紧，因为可以通过后序的ACK进行确认。
• 情况二：数据报丢了。
  
  当某一段报文段丢失之后，发送端会一直受到101这样的ACK，提醒发送端我想要的是101。
  如果发送端主机连续三次收到了同样的101这样的应答，就认为101数据包丢失，对其进行重传。
  这个时候接收端受到了101之后，再次返回的ACK就是501了（因为201~500）接收端其实之前就已经收到了，被放到了接收缓冲区。
  这种机制称为快速重传机制。

流量控制

接收端处理数据的速度是有限的。如果发端发的太快，导致接收端的缓冲区满了，这个时候如果发送端继续发送，就会造成丢包，继而引发丢包重传等一些列连锁反应。
因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制叫做流量控制。

• 接收端将自己可以接受的缓冲区大小放入TCP首部中的窗口大小字段，通过ACK通知发送端。
• 窗口大小字段越大，说明网络的吞吐量越高。
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置为一个更小的值通知给发送端。
• 发送端接收到这个窗口之后，就会减慢自己的发送速度。
• 如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。
  

接收端如何把窗口大小告诉发送端呢，TCP首部中，有一个16位窗口字段，就是存放窗口大小信息的，那TCP窗口最大就是65535字节吗？
实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位。

拥塞控制

虽然TCP有了滑动窗口，能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题。
因为网络上有很多计算机，可能当前的网络状况比较拥堵，在不清楚当前网络情况下，贸然发送大量数据，很可能是雪上加霜。
TCP引入慢启动机制，先发少量的数据，探探路，摸清当前的网络状况，再决定按照多大的速度传输数据。

• 此处引入一个概念为拥塞窗口。
• 发送开始时，定义拥塞窗口大小为1。
• 每次收到一个ACK应答，拥塞窗口加1。
• 每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小做比较，取较小的值作为实际发送的窗口。
  

像上面这样的拥塞窗口增长速度，是指数级别的。“慢启动”知识初始时满，但是增长速度非常快。

• 为了不增长的那么快，因此不能使阻塞窗口单纯的加倍。
• 此处引入一个叫做慢启动的阈值。
• 当拥塞窗口超过这个阈值的时候，不再按照指数方式增长，而是按照线性方式增长。
  
• 当TCP开始启动的时候，慢启动阈值等于窗口最大值。
• 在每次超时重发的时候，慢启动阈值会变成原来的一半，同时拥塞窗口置为1。

少量的丢包，我们仅仅是触发超时重传。大量的丢包，我们就认为网络阻塞。
当TCP通信开始后，网络吞吐量会逐渐上升；随着网络发生拥堵，吞吐量会立刻下降。
拥塞控制，归根结底是TCP协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。

延迟应答

如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小。

• 假设接收端缓冲区为1M，一次收到了500K的数据；如果立刻应答，返回的窗口就是500K。
• 但实际上可能接收端处理的速度很快，10ms之内就把500K数据从接收缓冲区取走处理掉了。
• 在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来。
• 如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是1M。
  

一定要记得，窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。
那么所有的包都可以延迟应答吗？肯定也不是。

• 数量限制：每隔N个包就应答一次。
• 时间限制：超过最大延迟时间就应答一次。

具体的数量和超时时间，不同的操作系统有差异。一般数量N取2，超时时间取200ms。

捎带应答

根据应用层协议，发送出去的消息到达对端，对端进行处理之后，会返回一个回执。例如，电子邮件协议的SMTP或POP、文件传输协议FTP中的连接控制部分等。
在此类的通信中，TCP的确认应答和回执数据可以通过一个包发送。这种方式叫做捎带应答。否则的话，如果确认应答单独发送的话，接受端对每一条数据的确认回复，都需要回复一个空报头，性能会比较低。
另外，接受数据以后如果立刻返回确认应答，就无法实现确认应答。而是将所接收的数据传给应用处理生成返回数据以后进而在进行发送请求为止，必须一直等待确认应答的发送。也就是说，如果没有启用延迟应答就无法实现捎带应答机制。

面向字节流

创建一个TCP的socket，同时在内核中创建一个发送缓冲区和接收缓冲区：

• 调用write时，数据会先写入发送缓冲区。
• 如果发送的字节数太长，会被拆分成多个TCP的数据包发出。
• 如果发送的字节数太短，就会先在缓冲区里等待，等到缓冲区长度差不多了，或者合适时机发送出去。
• 接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区。
• 然后应用程序可以调用read从接收缓冲区拿数据。
• 另一方面，TCP的一个连接，既有发送缓冲区，也有接收缓冲区，那么对于这一个连接，既可以读数据，也可以写数据。全双工。

由于缓冲区的存在，TCP程序的读和写不需要一一匹配，例如：

• 写100个字节数据时，可以调用一次write写100个字节，也可以调用100次write，每次写一个字节。
• 读100个字节数据时，也完全不需要考虑写的时候是怎么写的，既可以一次read100个字节，也可以一次read一个字节，重复100次。

粘包问题

• 首先要明白，粘包问题中的“包”，指的是应用层的数据包。
• 在TCP的协议头中，没有如同UDP一样的“报文长度”这样的字段，但是有一个序号这样的字段。
• 站在传输层的角度，TCP是一个一个报文过来的。按照序号排好序放到缓冲区中。
• 站在应用层的角度，看到的只是一串连续的字节数据。
• 应用程序看到这么一串的字节数据，就不知道从哪个部分开始到哪个部分结束是一个完整的应用层数据包。

如何避免粘包问题？
简言之一句话：明确两个包之间的边界。

• 对于定长的包，保证每次都按固定大小读取即可。
• 对于变长的包，可以在包头的位置，约定一个包总长度的字段，从而知道包的结束位置。还可以在包和包之间使用明确的分割符（应用层协议，程序猿自己定的，只要保证分隔符和正文不冲突即可）。

UDP协议存在粘包问题吗？

• 对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在。同时，UDP是一个一个把数据交付给应用层。就有很明确的数据边界。
• 站在应用层角度，使用UDP的时候，要么收到完整的UDP报文，要么不收。不会出现半个的情况。

TCP异常情况

• 进程终止：进程终止会释放文件描述符，仍然可以发送FIN。和正常关闭没有什么区别。
• 机器重启：和进程终止的情况相同。
• 机器掉电/网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不再了，就和进行reset。即使没有写入操作，TCP内置有保活定时器，会定期询问对方是否还在，如果对方不在，也会把连接释放。
• 另外，应用层的某些协议中，也有一些这样的检测机制。例如HTTP长连接中，也会定期检测对方的状态。例如QQ，在QQ断线之后，也会定期尝试重新连接。

基于TCP应用层协议

HTTP、HTTPS、SSH、Telnet、FTP、SMTP。

总结

• 可靠性：
  检验和、序列号（按序到达）、确认应答、超时重发、连接管理、流量控制、拥塞控制。
• 提高性能：
  滑动窗口、快速重传、延迟应答、捎带应答。

几个常见的问题

TCP连接管理中，为什么握手是三次，挥手是四次？

当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭socket，所以只能先回复一个ACK报文，告诉客户端，你发的FIN报文我收到了。但是需要等我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。所以需要四次握手。

若第三次握手失败，服务端如何处理？

第三次握手失败时，服务器并不会重传ACK报文，而是直接发送RTS报文段，进入CLOSED状态。这样做的目的是为了防止SYN泛洪攻击。

什么是SYN泛洪攻击？

SYN泛洪攻击利用TCP三次握手进行攻击。攻击者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当服务器返回ACK后，攻击者不对其进行确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到确认的话，就会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送大量这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务了。

服务端出现大量TIME_WAIT状态的原因？

服务端有大量的短连接主动关闭。

服务端出现大量CLOSE_WAIT状态的原因？

服务器进入了CLOSE_WAIT状态，结合四次握手的流程图，可以认为四次握手没有正确完成。对于服务器上出现大量的CLOSE_WAIT状态，原因就是服务器没有正确的关闭socket，导致四次握手没有正确完成，这是一个BUG，只需要加上对应的close即可解决问题。