计算机网络-TCP

一. TCP的服务

1. TCP服务介绍

  1. TCP提供一种面向连接的可靠的字节流服务
  2. 面向连接以为着两个使用TCP的应用在彼此交换数据之前必须建立一个TCP连接
  3. 在一个TCP中,仅有两方进行交流

1.1 TCP通过以下方式来提供可靠性

  1. 应用数据被分割成TCP认为最适合的数据块
  2. 当一个TCP发出一个段后,他启动一个定时器,等待目的端确认收到这个报文段,如果不能及时收到一个确定,将重发这个报文段
  3. 当TCP收到来自TCP连接另一端的数据,他将发送一个确认,这个确认通常将推迟几分之一秒
  4. TCP将保持它首部和数据的校验和
  5. TCP报文作为IP数据报来传输,IP数据报的到达可能失序,因此TCP收到的报文段也可能会失序,必要时TCP将对收到的数据进行重新排序,将受到的数据已正确的顺序交给应用层
  6. IP数据报会重复,TCP接收端必须丢弃重复的数据
  7. TCP提供流量控制,TCP连接的每一方都有固定大小的缓冲空间,TCP的接收端只允许另一端发送接收端穿冲去所能接纳的数据。防止较快主机致使较慢主机的缓冲区溢出

1.2 TCP字节流

  1. 两个应用程序通过TCP连接交换8bit字节构成的字节流
  2. 比如一方应用先传10字节,再传20,再传50,连接的另一方将无法了解发放每次发送了多少字节。收方可分4次接受这80个字节,每次接受20字节
  3. TCP不对字节流作任何解释。对字节流的解释由TCP连接双方的应用层解释

2. TCP包结构

在这里插入图片描述
在这里插入图片描述

2.1 各字段解释

  1. 源端口、目的端口:用于寻找发端和收端应用程序。这两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接
    (一个IP地址和一个端口号也成为一个插口、插口对)
  2. 序号:用来标识TCP发送端向TCP收端发送的数据字节流,它标识在这个报文段中的第一个数据字节的序号(即数据部分的第一个字节)(TCP用序号对每个字节进行计数。序号是32bit的无符号数,序号到达2的32次方后又从0开始,SYN标志消耗了一个序号)(序号是接收方知道收到啥)
  3. 确认序号:应当是上次已成功收到数据字节的序号+1.只有ACK标志为1时确认序号字段才有效(确认序号是让发送方知道下一次发啥)
  4. 首部长度4bit,即TCP头部最多60字节(一般20个)
  5. TCP首部中有6个标志比特
    • URG:紧急指针有效
    • ACK:确认序号有效
    • PSH:接收方应该尽快将这个报文段交给应用层
    • RST:重建连接
    • SYN:同步序号用来发起一个连接
    • FIN:发送端完成发送任务
  6. 16位窗口大小:TCP的流量控制机制(滑动窗口协议,提高信道利用率)由连接的每一端通过生命的窗口大小来提供。窗口大小为字节数,这个值是接收方控制发送发可以连续发送未经确认的报文数量(假设B发给A的窗口大小size,则A可以在未收到ACK的情况下连续发送size字节)
  7. 校验和:覆盖了整个TCP报文段(TCP首部+TCP数据),TCP是强制的(UDP不是强制),同UDP有一个伪首部
  8. 紧急指针:URG为1是有效, 一个正的偏移量,和序号字节中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式
    (TCP通过连接传送的唯一信息就是紧急方式已经开始,还有指向紧急数据的后一个字节的指针,其他事情交给应用程序)
  9. PUSH标志:PSH位是1,发送方使用该标志通知接收方将所收到的数据全部提交给接收进程,包括缓存区以及同PUSH一起传过来的数据
  10. 最常见的可选字段是最长报文大小,即告诉另一端本端所能接收的最大长度的报文段
  11. TCP报文段中的数据部分是可选的。即可以没有数据

2.2 序号和确认序号图解

在这里插入图片描述

2.3 TCP 一些性质

  1. 发送ACK无需占用任何符号,因为32bit的确认序号字段和ACK标志一样,总是TCP首部的一部分。因此,我们看到一旦一个连接建立起来,这个字段总是被设置,ACK标志也总是被设置为1
  2. TCP为应用层提供全双工服务(即时刻可以发送和接收)
  3. TCP是一个没有选择确认或否认的滑动窗口(现在有了)

2.4 选择确认或否认

  1. 假设一个流的1 ~ 1024字节已经成功收到,而收到的下一报文段中包含 2049 ~ 3072 (即丢失 1025 ~ 2048)
  2. 收端不能确认这个新的报文段(2049 ~ 3072)它所能做的就是发回一个确认序号为1025的ACK(无法选择确认)
  3. 它也无法对一个报文段进行否认。例如收到包含1025 ~ 2048字节的报文段,但是校验和错误。它所能做的就是发回一个确认序号为1025的ACK(无法选择否认)

TCP建立和终止

参考:

  1. TCP三次握手和四次挥手
  2. TCP三次握手和四次挥手
  3. TCP连接状态详解

三次握手图解

在这里插入图片描述

  • LISTEN:侦听并等待对端的TCP连接请求
  • SYN-SENT:发送SYN连接请求后,等待对端回复SYN请求
  • SYN-RECEIVED:收到来自对端的SYN请求,并回复SYN请求后,等待对端响应SYN请求的ACK消息
  • ESTABLISHED:代表连接建立,双方在这个状态下进行TCP数据交互

四次挥手图解

在这里插入图片描述

  • ESTABLISHED:代表连接建立,双方在这个状态下进行TCP数据交互
  • FIN-WAIT-1:发送FIN关闭连接请求后,等待对方响应FIN的ACK消息或者对端的FIN关闭请求
  • FIN-WAIT-2:等待对方FIN关闭请求
  • CLOSE-WAIT:等待本地用户(进程)发送FIN关闭请求给对端
  • CLOSING:当双方同时发送FIN关闭请求时,会进入CLOSING状态,等待对端发送FIN报文的响应ACK消息
  • LAST-ACK:收到对端FIN请求后,回复ACK及FIN并等待对方回复FIN的响应ACK消息,此时进入此状态
  • TIME-WAIT:该状态是为了确保对端收到了FIN请求的ACK响应,默认会等待两倍MSL时长(MSL:Maximum Segment Lifetime,即报文最大生存时间,超过这个时间的报文会被丢弃)

TCP数据传输过程 - TCP交互数据流

先看一下

交互式输入

每个交互按键都会产生一个数据分组,产生4个报文段

  1. 来自客户的交互按键
  2. 来自服务器的按键确认
  3. 来自服务器的按键回显
  4. 来自客户的按键回显确认

经受时延的确认

通常TCP在接收到数据时并不理解发送ACK;而是以最大200ms的时延等待是否有数据一起发送

Nagle算法

数据小时,路径上只能有一个未被确认的大分组,在ack到达前,缓存其他小分组,在确认后将这些分组作为一个大分组一起发送,若要有实时性,需要关闭该算法

TCP数据传输过程 - TCP成块数据流

滑动窗口协议

在这里插入图片描述

  1. 当ack=7,win = 8的报文到达后,则窗口左边移动到ack值的位置7,右边则是ack+win = 15
  2. 窗口大小由接受方上一个ack中的16位窗口决定,即可以发送6个数据而不用确认
  3. win = 0表示缓存区已经满,发送方会先不发,等待接收方的win = xxx 的窗口更新报文

TCP拥塞控制

一般原理

  1. 出现资源用塞的条件:对资源需求的总和>可用资源
  2. 拥塞控制是一个全局性的过程,涉及到所有的主机、所有的路由器,以及与降低网络传输性能有关的所有因素
  3. 流量控制往往之在给定的发送端和接收端之间的点对点通信量的控制,他所要做的就是抑制发送端发送数据的速率,以便使接收端来得及接收
  4. 吞吐量:一秒钟通过该路段(链路、路由器)的所有流量
  5. 发送窗口的上限值 = Min(rwnd,cwnd)(滑动窗口(接收方B决定),拥塞窗口(发送方A控制))
  6. 拥塞窗口是发送方使用的流量控制,滑动窗口是接收方使用的流量控制

拥塞

在这里插入图片描述

  1. 由于路由器要处理传进来的所有包(不管这个包最后有没有传出去),因此发的越多,最终能传出去的反而越少
  2. 理想情况(红线)是达不到的
  3. 无拥塞控制会出现绿色线条情况

慢开始算法

在这里插入图片描述

  1. ssthresh(慢开始门限)
    • cwnd<ssthtrsh:用慢开始算法
    • cwnd>ssthtrsh:停止慢开始算法,改用拥塞避免算法
    • cwnd=ssthtrsh:即可用慢开始,也可用拥塞避免
  2. 拥塞避免算法:容拥塞窗口cwnd缓慢增大,即每经过一个往返时间RTT就把发送方的拥塞窗口加1,而不是加倍,使拥塞窗口cwnd按现行规律缓慢增长
  3. 当TCP连接进行初始化时,将拥塞窗口(cwnd)设置为1(窗口单位不使用字节而使用报文段)
  4. 慢开始门限(ssthtrsh)的初始值是16个报文段
  5. 无论在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(其根据是没有按时收到确认),就把慢开始门限ssthresh设置为出现用拥塞时的发送方窗口值的一半(但不能小于2),然后把拥塞窗口的cwns重新设置为1,执行慢开始算法

快重传和快恢复

在这里插入图片描述

  1. 快重传:丢包时(比如收到1,2,4),快速发送3个重复确认包(ack =3)
  2. 快恢复:收到3个重复的确认(说明网络还不拥塞),则将ssthresh设为当前拥塞窗口的一半(需要先加上三个报文段大小,再折半),然后将拥塞窗口设为新ssthresh(拥塞门限)的值并执行拥塞避免算法

TCP超时重传

基本

  1. 重传间隔指数增长
  2. RTO:多久时间后就不再重传
  3. RTT = &RTT+(1-&)M;(&一般为0.9,M是新的测量值)
  4. RFC793:RTO = RTT*@(@一般为2)
  5. jacobson:RTO = A+4D(A是被平滑的RTT,D是被平滑的均值偏差)

1. 重传时间计算

  1. 每个TCP任何时候对每个连接仅测量一次RTT,如果ACK到达时数据没有被重传(定时器没有超时),则被平滑的RTT和被平滑的均值偏差将更新
  2. 初始时,RTO = A+2D (A初始值是0,D初始值是3s)
  3. 当超时在6s之后,则RTO = A+4D

2. 分组丢失指示

  1. 超时,没有ack,需要好的RTT算法(慢开始)
  2. 收到重复的确认:收到3个ack,说明丢包(快重传、快恢复)

TCP计时器

1. 重传定时器

用于发送一个数据报文时,在规定时间内发送方需要受到另一端的接收报文确认,即超时重传的RTO

2. 坚持定时器

使窗口大小信息保持不断流动,即使另一端关闭了其接收窗口

  1. 原因:如果一个通告窗口更新的确认丢失了,则双方可能一直等待
  2. 解决:为了防止这种死锁,发送方使用了一个坚持定时器来周期性的向接收方查询,以便发现窗口是否已增大,发送方发出的报文段成文窗口探查

3. 保活定时器

用于检测一个空线连接的另一端是否依然还保持连接
如果给定的连接在两个小时之内没有任何动作,则服务器就可以向客户发送一个探查报文段

  1. 主机、服务器均正常,TCP响应正常
  2. 主机崩溃,再重启或者已经关闭,或者服务器不可达。客户的TCP响应到达不了服务器,服务器不能够收到对探查的相应,并在75s后超时。服务器总共发送10个这样的探查,每个建个75s,若均为相应,则关闭连接
  3. 客户端主机已经重新启动,这时服务器将收到一个对其保活探查的相应,但是这个响应是一个复位,使得服务器终止这个链接

4. 2MSL定时器

一个连接处于TIME_WAIT状态的时间,四次挥手

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值