您的位置: 首页  >  文章  >  TCP连接

TCP连接

分类: 文章 • 2025-04-13 19:43:40

RTT(Round Trip Time) TCP从发送数据包到收到响应消耗的时间。
TCP需要解决的是 可靠传输以及乱序的问题。

  1. tcp超时重传
    发送数据之后开启一个计时器，一定时间内如果没有得到发送数据包的ACK报文， 那么就重新发送数据。
    参数 RTO(Retransmisson Timeout) 设置长，重发慢没有效率，性能差，设置短，重发快网络拥塞，更多超时。

  2. tcp滑动窗口
    可靠性、流控

滑动窗口根据接收方接收数据的情况对发送方进行流量控制，从而减少网络负担。
字节流分为四部分：

  1. 收到ack确认数据 2. 发送了还是没收到ack 3. 在窗口中还未发出去 （接收方还有空间）4. 窗口以外

根据接收端传来的tcp头部字段 window的大小调整滑动窗口的大小。

  1. 拥塞窗口
    发送端与接收端中间设置的传输能力
    滑动窗口仅仅依赖于连接的发送端以及接收端，网络中间过程不能体现。（例子：网络延迟增大，丢包，重发，拥塞，更大延迟以及丢包）

设置拥塞窗口来表示发送端以及接收端中间过程的传输能力。然后对应拥塞控制算法。

  1. 拥塞控制

慢启动 将拥塞窗口设置为1， 然后拥塞窗口指数级增长
拥塞避免 当拥塞窗口大小等于慢开始门限阈值，执行拥塞避免，拥塞窗口线性增长。

当出现超时时，将慢开始门限设置为出现拥塞时拥塞窗口大小的一半，然后拥塞窗口设置为1，执行慢启动。

快速重传

  1. 接收方收到一个失序的报文段立即发送ack给发送方
  2. 发送端收到三个重复确认之后就开始重传，不用等到RTO超时

快速恢复
发送端出现超时重传或者连续收到三个重复确认号，执行乘法减小，将慢开始门限减半，但是不执行慢启动算法，而是将拥塞窗口设置为慢开始门限减半之后的数值，然后执行拥塞避免算法（加法增大）。

  1. TCP流量控制
    发送端以及接收端的发送、接收速率大小影响网络性能，最好能够达到一种动态平衡。
    流量控制的本质也是对发送端发送速率的控制。

接收方每次收到数据包，在发送ack报文的时候会将接收缓存区窗口大小告诉发送端。当发送端收到之后，就会调整发送端发送窗口的大小。当发送端发现接收端窗口大小为0时，停止发送，防止出现大量丢包。

但是什么时候让发送端再发送数据呢？ 发送端停止发送的时候开启一个定时器，每隔一段时间发送测试报文询问接收方，是否可以发送，接收端回复当前接受窗口的大小。接受窗口大小为0，重新启动定时器。

  1. tcp各种信号

6位标志位: URG（紧急指针） ACK PSH（接收端是否立即读取）RST（重新建立连接）SYN(请求建立连接) FIN(告诉对方本端要断开连接)
TCP连接

  1. tcp连接与关闭
    TCP连接
    tcpudmp 从第三个报文段开始，序号值以及确认值都是相对于初始值的偏移。
    tcp连接时全双工的，允许两个方向数据传输被独立关闭。发送端发送结束报文段给对方，通知本端已经完成数据发送，但是允许数据接收，直到对方也发送结束报文段关闭连接。
    这种状态称为半关闭状态。

tcp状态转移
TCP连接
为什么需要三次挥手、四次握手

TIMEWAIT状态
发送端收到接收端结束报文段并不直接进入CLOSED状态，而是进入TIME_WAIT状态，等待2*MSL（Maximum Segment Life）报文段最大生存时间，才能关闭。

原因一： 可靠终止TCP连接
考虑发送端回复接收端结束报文的确认报文段丢失，接收端会重发结束报文段，发送端需要停留在某个状态处理这种情况， 否则发送端会发送复位报文段回应服务器。

原因二：保证迟来的TCP报文段有足够时间别识别并丢弃
如果没有TIMEWAIT状态，新开一个连接与原来的连接具备相同的ip地址和端口，会接收到原来连接的报文段（携带应用程序）。TIMEWAIT下所有回到的报文段都被丢弃。

为什么这个时间是2MSL?
发送端需要确认接收端收到自己的ack， 有两种情况：

  1. 接收端超时重传FIN
  2. 接收端收到了ack， 不会发送任何报文
    因此发送端等待时间必须为两者最大值，第一种情况需要ack报文生存的最大时间 + 重传fin的最大生存时间，刚好是2MSL

通过设置SO_REUSEADDR选项解决TIME_WAIT状态

为什么要进行三次握手呢？

  1. 这是为了避免已经失效的连接请求突然传送到服务端，产生错误。
  2. 三次握手的过程即是通信双方相互告知***起始值， 并确认对方已经收到了***起始值的必经步骤

**假设客户端发出的连接请求滞留，**然后客户端重发报文，回复报文建立连接。但是此时若滞留额连接请求到访，服务端则会重新新建一个连接。这是错误的，而且浪费资源。
如果是三次握手，服务端收到建立连接请求之后，回复，但是客户端不会理会这个报文（或者说会发送reset报文，但是服务端不会理会）。

建立三次挥手，但是关闭却需要四次挥手的原因？
TCP是全双工的，可以单独关闭某个方向的通道。在建立tcp连接时，服务端回复的是 ACK/SYN，其中ACK是用于确认，让客户端知道你的报文我收到了，SYN用于同步建立连接。但是在关闭tcp连接时，服务端第一次回复的是ACK，只是告诉客户端你的报文我收到了。此时只关闭了从客户端到服务端的通信，只有等接收端所有报文发送完成了，才能关闭从服务端到客户端的通信

相关推荐