什么是TCP传输协议
传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议。
TCP协议段格式
- 16位源端口号：标识数据来自哪个进程；
- 16位目的端口号：标识数据去向哪个进程；
- 32位序号：用来标识从TCP发送端向接入端发送的数据字节流进行编号；
- 32位确认号：确认号包含发送确认的一端所期望收到的下一个序号；
- 四位首部长度：用于表示TCP报文首部的长度，首部长度大小乘以4表示得到报文头部有多少个字节。四位最大为15 X 4 = 60字节，为报文头部最大长度；
- URG：表示紧急指针是否有效；
- ACK：确认号是否有效；
- PSH：提示接收端应用程序应该立即从TCP缓冲区把数据取走；
- PST：对方要求重新建立连接，我们把携带RST标识的称为复位报文段；
- SYN：请求建立连接，我们把携带SYN标识的称为同步报文段；
- FIN：通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段；
- 16位窗口大小：TCP流量控制由连接的每一端通过声明的窗口大小来提供
- 16位检验和：发送端填充，CRC校验，接收端校验不通过，则认为数据有问题。此处的检验和不光包含TCP首部, 也包含TCP数据部分.
- 16位紧急指针：标识哪部分数据是紧急数据。
- 选项：长度为0-40B（字节），必须以4B为单位变化，必要时可以填充0。通常包含：最长报文大小（MaximumSegment Size，MSS）、窗口扩大选项、时间戳选项、选择性确认（Selective ACKnowlegement，SACK）等。
- 数据
确认应答机制
确认应答机制简单的来说，就是A端口向B端口发送数据，但是为了保证每次发送的数据都是正确有效的，B端口收到数据后，进行校验，发现是我想要的，就会给A端口回复确认信息，告知我已经收到了正取信息，请继续给我发送下一个信息。
只有当收到确认信息之后，才会进行下一个数据包的发送。
超时重传机制
超时重传机制：主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B。
如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发。
- 在数据发送时数据丢失
- 在回复确认包时数据丢失
但主机B会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包，并且把重复的丢弃掉。这时候我们可以利用前面提到的序列号，就可以很容易做到去重的效果。 - 最理想的情况下，找到一个最小的时间，保证 “确认应答一定能在这个时间内返回”。
- 但是这个时间的长短，随着网络环境的不同，是有差异的。
- 如果超时时间设的太长，会影响整体的重传效率。
- 如果超时时间设的太短，有可能会频繁发送重复的包。
TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。
- Linux中(BSD Unix和Windows也是如此)，超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。
- 如果重发一次之后，仍然得不到应答，等待 2*500ms 后再进行重传。
- 如果仍然得不到应答，等待 4*500ms 进行重传，依次类推，以指数形式递增。
- 累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。
滑动窗口机制
刚才我们讨论了确认应答策略，对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。
那么我们是不是可以同时发送多条数据，再同时等待多个应答呢？这便产生了滑动窗口机制
- 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节(四个段)。
- 发送前四个段的时候, 不需要等待任何ACK, 直接发送;
- 收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;
- 操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答。只有确认应答过的数据，才能从缓冲区删掉。
- 窗口越大，则网络的吞吐率就越高。
- 数据发送成功，但确认回答数据包丢失
这种情况下应答包丢失并不要紧，因为我们可以通过后面的确认包知道前面的数据时已经发送了。
- 数据发送时丢包
- 当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 "我想要的是 1001"一样;
- 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送。
- 这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中;
延时应答机制
如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小。
- 假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;
- 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
- 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
- 如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;
一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;
简单的来说延时机制为的是在数据接收时能够尽可能的接收更多的数据，所有我们在回复应答数据时延迟回答，尽可能少的占用窗口数据，等数据从接收缓冲区取走之后我们在进行应答回复。
捎带应答机制
在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 "一发一收"的。意味着客户端在向服务端发送数据之后，服务端也会回给客户端一个数据。那么这是应答包就可以跟着服务端要发送的数据，一起发向给服务端。从而减少了数据包发送的次数
转载：https://blog.csdn.net/weixin_44030298/article/details/105875302