TCP/IP协议学习——TCP协议（2）

1. TCP协议的并发处理

    1. TCP协议通过端口号来确定主机上要通过TCP连接来收发数据的进程或者说应用程序。但是，一个服务端通常会对应多个客户端，也就是说在服务端的一个端口上会有多个TCP连接；在Linux系统中，服务端每接收到一个新的TCP连接请求，就会fork一个新进程进行处理，问题就在于对同一端口下已建立的多个TCP连接同时收发数据时如何区别处理的？

    TCP协议采用了源IP地址+目标IP地址+源端口号+目标端口号来确定一个唯一的TCP连接，将接受的数据依据这四个信息分发到各个对应的TCP连接进程中。使用netstat命令就可以看到自己电脑上每个端口下的TCP连接进程以及进程状态（可以详细了解一下netstat命令的使用）。

    2. 同时对服务端一个端口发起的多个TCP连接请求如何处理：一个并发服务器调用一个新的进程来处理每个客户端TCP连接请求，因此处于被动连接请求的服务器应该始终准备处理下一个呼入的TCP连接请求。但仍有可能出现当服务器在创建一个新的进程来处理TCP连接请求时，或操作系统正忙于处理优先级更高的进程时，到达多个连接请求。当服务器正处于忙时， TCP是如何处理这些呼入的连接请求？

（1）TCP的实现中有一个TCP连接队列，该队列是用来保存那些已经完成建立连接，但是还没有被应用层所接受（使用）的TCP连接，如果应用层接受，该连接就会从队列中移除。应用层可以明确指定该队列的长度，这个长度值通常称为积压值，取值范围为0-5。

（2）当一个连接请求（即SYN）到达时，TCP使用一个算法，依据连接积压队列中积压的连接数量来确定是否接收新的连接请求

（3）如果收到新的连接请求后，积压队列中还有空间，那么就可以建立连接；否则不会理会新的连接请求（SYN），也不会响应任何报文段，直到该连接超时，除非应用层能及时接受积压队列中的TCP连接。

2. TCP超时与重传

    1. TCP是一个面向连接的、可靠的协议，其对于数据传输的可靠性会通过确认应答机制（ACK字段）来实现。

    2. 确认应答：当发送方主机发送数据后，会进入等待确认状态，等待目标主机的应答；数据传输到目标主机后，目标主机会响应一个消息通知表示自己接收到了数据（TCP首部的ACK控制字段位置为1），发送方主机收到这条确认应答消息后就可以继续发送下一个数据，如果超过一段时间没有接收到确认应答消息，那么就表示数据可能已经丢失，发送方主机会重新发送数据。在确认应答机制的保证下，即使发生丢包也能保证数据达到目标主机。

    3. 未收到确认应答不代表数据丢失：

（1）数据包在网络中滞留，比如滞留在某个路由节点上无法发送导致目标主机无法接收并进行应答确认，然后就会超时，发送端就会丢弃该数据包进行重发（当路由节点不在拥塞，超时的数据包还是会发送到目标主机，但是源主机重发了一个相同的数据包，导致数据包重复发送）。

（2）目标主机已经收到数据，但返回的确认应答在传输途中丢失，或者也是滞留在传输线路中，也会导致源主机重发，引起数据包重复发送。

    4. 由于源主机数据确认应答超时导致目标主机重复接收相同数据问题：对于源主机来说，确认应答超时只需要重发数据包即可，但对于目标主机来说，就会重复收到多个同一数据包，而这对于应用层的应用来说是“灾难”。所以，TCP必须实现一种机制能够放弃重复数据包，能够识别已接收的数据并且判断是否需要接受数据。而这些机制的实现方式就是通过TCP首部中的序列号（32bit）实现。

TCP首部信息中的序列号字段用来标识从TCP发端向TCP接收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。序号是32bit的无符号数，序号到达2^32－1后又从0开始。

    5. 接收端在接收到TCP数据包后，通过TCP首部的序列号和数据长度，确定下一个应该接收到的数据包的序列号并作为确认应答返回。

3. TCP的数据传输单位——报文段

    1. 在TCP连接建立的同时，也会确定传输的最大报文段长度（每次传输的最大数据量），在TCP首部信息的选项字段部分中的MSS字段表示该值，在发送端发送大量数据时，就是以MSS为单位对总数据进行分割，然后再进行发送。

    2. MSS的确定：在TCP连接建立时，两端的主机就会告知各自的MSS，在第三次握手的时候，两端都已经获取到对方的MSS，通过比较之后，选择较小的MSS作为传输分割单位。最佳情况下应该MSS应该是IP分片处理中不会被分割的最大数据长度。

4. TCP的窗口控制提高TCP通信性能

    1. 确认应答机制有一个缺点：如果必须一次报文段发送对应一次应答才能发送下一段数据的话，那么这会造成很大的性能损耗，尤其是当数据往返时间较长时。为了解决这个缺点，TCP中使用了窗口控制机制。

    2. 窗口控制：其实原理比较简单，不再是以每一个报文段发送后都要等待对应的一次数据应答，而是连续发送多个数据包，然后等待返回确认应答消息，这就是窗口机制。窗口大小就是指无需等待连续发送数据的最大数据段数。

    3. 滑动窗口机制：窗口机制可以通过下面两个图更好的理解，窗口内的数据段是可以连续发送而且不需要立即确认应答的，窗口以外的部分包括了已经收到确认应答的数据段和等待窗口内数据段发送成功的未发送数据段。每当窗口内的数据段发送成功（收到确认应答）后，就会向未发送的数据段方向进行移动。

（1）发送方不必发送一个全窗口大小的数据。

（2）来自接收方的一个报文段确认数据并把窗口向右边滑动。这是因为窗口的大小是相对于确认序号的。

（3）窗口的大小可以减小，但是窗口的右边沿却不能够向左移动。

（4）接收方在发送一个 ACK前不必等待窗口被填满。

    4. 滑动窗口机制中的数据丢失处理方式：滑动窗口机制中，数据的发送仍然是有可能丢失的，有两种丢失情况，一种是确认应答超时或丢失，另一种是数据超时或丢失。

（1）确认应答超时或丢失：因为实际上目标主机已经收到了数据，所以只要其下一个数据段成功返回了确认应答信息，就代表之前的数据已经收到了，所以不需要进行重发。

（2）数据超时或丢失：目标主机依据序列号没有接收到应该接受的数据段，就会不断的向源主机发送缺失数据段的确认应答消息，源主机接收到后就会重发

    5. 窗口实现的流控制功能：上面说的是发送方的窗口大小设置可以起到一个发送缓冲的效果；而对于接收方来说，窗口设置是用来限流的。有一种情况就是，发送方发送的数据段可能会需要一些时间处理，而处理的时候可能无法回复确认应答甚至是无法接收数据，而无法接收数据就会导致数据重发，进而导致网络流量浪费。所以就需要接收方的窗口来实现流控制能力。

    接受方会不断告诉发送方自身的窗口大小，也就是自己所能接收的数据大小，而发送方依据该数据就不会发送超过该大小的数据量，所以说窗口大小是由接收端规定的，而不是发送端。