【计算机网络】Tcp详解

文章目录

  • 前言
  • Tcp协议段格式
  • TCP的可靠性
  • 面向字节流
  • 应答机制
  • 超时重传
  • 流量控制
  • 滑动窗口(重要)
  • 拥塞控制
  • 延迟应答
  • 捎带应答
  • 标志位
  • 具体标志位
  • 三次握手
  • 四次挥手
  • 粘包问题
  • TCP异常情况
  • listen的第二个参数

前言

前面我们学习了传输层协议Udp,今天我们一起学习Tcp,Tcp比Udp复杂,但可靠,非常多的场景需要这种可靠。

Tcp协议段格式

【计算机网络】Tcp详解_第1张图片

只从格式来看,Tcp就比Udp复杂许多,那么Tcp的报头和有效载荷应当如何分离?

首先,报头前20个字节一定是固定的,我们先提取前20个字节,找到4位首部长度
然后,首部长度 * 4 -20,来查看是否有选项
最后,读完选项的字节,剩下的就是数据。

TCP的可靠性

大量丢包,乱序,重复,校验失败,发送缓慢,网络故障,都是不可靠的表现,正是因为传输距离变长,才会引发如此多的可靠性问题,为了解决这些问题。TCP引入了应答进制

假如C给S发送了一条数据,只有当S给C了应答,C才认为自己的数据已经送到了S的手里,如果等待一段时间后没有收到这个应答,C就会认为自己发送的数据丢失了,会触发超时重传。

为了提高发送的效率,多个TCP报文会同步传送,这也就导致到达对端的数据没有顺序,而乱序正是我们要可靠问题,所以TCP报文注定是有编号

面向字节流

应用层将数据拷贝到TCP的发送缓冲区,以 uint8 为一个单位将整个发送缓冲区划分。所以发送缓冲区天然带编号(数组下标)。

应答机制

上面我们知道TCP需要应答和编号,应答其实就是一个TCP报文中携带了ACK字段,而32位序号就是我们所说的编号,对端需要针对这个序号对我们做出ACK应答。

例如:C端发出了32位序号为10的报文,S端就要返回一个32确认编号为11的报文

发送序号:当前报文的编号。
确认序号:表示前面的报文已经全部收到,接下来应该从这个序号开始发送了。

由于Tcp报文具有捎带应答机制,即S发送ACK的时候,也有想要发给C的信息,所以必须设计为两个独立字段,而不能复用在一起。

超时重传

数据丢失的两种可能性:
1、数据半路真的丢包了
2、数据没有丢包,但ACK半路丢了

第一种情况,必然需要我们重传数据,也就要求TCP必须能做到暂时保存这些数据,以支持重传。
第二种情况,可以参考其他的ACK,因为如果只是ACK丢失,其他ACK的确认序号不会变。

等待时间:各个平台不同,在linux下以500ms为基准,n*500的方式动态调整。

流量控制

TCP具有接收缓冲区和发送缓冲区,也是全双工的,但只要是缓冲区就有大小,设想一下这样的场景:

C将报文送到了S,但S的接收缓冲区放不下了。在这种情况下,S只能丢弃掉来的报文,并不做应答,过一段时间,C会进行重传操作。

仔细一下就会发现这样是十分低效的,报文千里迢迢赶到对端主机,却因为对端没法接收而被丢弃,为了解决这个问题,TCP报文有一个叫做16位窗口大小的字段,这个字段填充自己的接收缓冲区的大小,对方拿到报文时就会看到这个大小,并根据此大小调整(增大或减小)发送数据的速度、大小。

窗口探测:
双端会定期向对方发送不携带数据的TCP报文,以此来询问对方的接收能力,调整自己发送数据的速度和大小(这个过程是双向的)

滑动窗口(重要)

TCP协议,可靠性是主要的研究问题,但效率问题,也是TCP需要考虑的问题。

发送方并发发送,一定要在对方能够接收的前提条件下,才能进行并发发送。

1、一般情况
【计算机网络】Tcp详解_第2张图片

一个发送缓冲区就被滑动窗口划分成了三个区域。

左边的区域:已经发送,且已经确认的数据——可以被覆盖的
中间的区域:可以直接发送(大小限制),但尚未收到应答
右边的区域:尚未发送的数据区域

滑动窗口的大小,应该与与对方的接收能力有关。

1.5、如何理解滑动窗口

【计算机网络】Tcp详解_第3张图片

2、特殊情况

1、滑动窗口只能向右,因为左边的数据已经没有了意义

2、变大变小本质是在调整winend,取决于对方的窗口大小,滑动窗口是浮动的

3、变成0,说明对方不能接收数据了(进行窗口探测,窗口通知)

4、应答也要按序到达
应答编号:winstart = seq;
应答窗口大小:winend = winstart + win;

5、丢失问题

a、第一个丢失了
重传补发

b、中间的丢失了
向右滑动,又变成了第一个丢失

c、最后一个丢失
也会变成最左侧丢失

快重传:(高速重发)
当某一个报文丢失,连续收到了三个一样的确认应答后,立马进行重传。

重传的下限:超时重传
重传的上限:快重传

拥塞控制

如果网络出现问题,TCP也进行了策略控制。

同样都是丢包,丢少和丢多也是不一样的,如果一直在丢包,那就是网络的问题。

当大量丢包的时候,发送方的发送策略是 等等再发!!

如果网络出现瘫痪的时候,所有主机再次重传,会让瘫痪的网络更难以恢复,所以我们采用的策略是,如果发现了网络拥塞,要减少发送量。总的来说要符合以下两点要求:

1、保证网络拥塞不能加重
2、在网络恢复有起色时,尽快恢复网络通信

TCP引入了 慢启动 机制:

发生了网络拥塞,发送方要基本得知网络拥塞的严重程度,必须进行网络状态的探测

拥塞窗口
需要对网络状况进行衡量——拥塞窗口

网络状态时变化的,衡量网络健康状态,即拥塞窗口的大小一定是变化的。

因此发送方的滑动窗口 = min(16位窗口大小,网络的拥塞窗口)

拥塞窗口的增长速度是指数级别的,慢启动指的是前期慢,后期增长速度非常快。

1、慢启动有一个阈值
2、当拥塞窗口超过这个阈值后,不再指数增长,而是按线性增长
3、每次超时重发的时候,慢启动阈值(ssthresh)会变成原来的一半,同时拥塞窗口置为1(乘法减少)

延迟应答

立即返回ACK应答,返回的窗口大小可能会比较小。

给对方通告出更大的win大小,对方就能在更大概率上提高传送效率。给上层更多时间来读取,在这段时间尽快读取,且读取更多。

捎带应答

ACK搭顺风车。

标志位

  • 标志位的本质

一个二进制位,来标识不同类型的报文

  • 为什么要有标志位

不同的标志位提供不同的服务。

具体标志位

ACK:确认应答报文,可能携带数据(捎带应答)
SYN:连接请求的报文(三次握手)
FIN:连接断开的报文(四次挥手)
PSH:提示对方应用层尽快将缓冲区数据取走(多路转接
RST:告诉对方要重新连接(连接被重置了)
URG:按序到达,但我们想插队?(紧急数据)16位紧急指针,紧急数据在有效载荷中的偏移量。紧急数据(带外数据)只有一个字节。(下载取消案例)recvfrom的MSG_OOB选项。

三次握手

【计算机网络】Tcp详解_第4张图片

  • 1、什么是连接?
    一个OS内一定右多个建立好的连接,OS必须要把这些连接管理起来。
    维护连接是有成本的,必然要消耗CPU、内存资源。

  • 2、为什么是三次?
    三次握手过程,由双方操作系统在TCP自主完成
    connect:触发连接,等待完成
    accept:等待建立完成,获取连接

    对于客户端来说,只要发出了最后一个ACK,就认为链接已经建立好了。
    对于服务端来说,只有收到了最后一个ACK,服务器才消耗资源构建。

    因此,三次握手本质在赌服务端的确收到了最后一个ACK。假如没有收到ACK,两者建立认知不一致了,这时候客户端再给服务端发消息,服务端就会回复一个RST,进行连接重置

    • 如果两次握手,只要发出SYN+ACK就得浪费资源构建。容易被SYN洪水攻击。注意,TCP本身并不考虑解决安全问题,但TCP不能出现安全漏洞!因此需要规避SYN洪水。
    • 如果大于3次握手,仍然解决不了最后一个ACK问题,如果是偶数次握手,最后一个ACK是服务器端承担风险、奇数次握手是客户端承受风险。而服务器端保存着大量的数据,出现异常是必然的,固而两次以及偶数握手是不妥的
    • 3次握手的好处:
      1、没有明显漏洞,出现异常,成本嫁接到客户端
      2、验证双方通信信道通畅情况,是验证流畅(全双工)的最小成本(收、发)
  • 3、状态变化
    SYN_SENT:同步发送
    SYN_RCVD:同步收到
    ESTABLiSH:建立完成

四次挥手

【计算机网络】Tcp详解_第5张图片
四次挥手,是双方建立连接断开共识的最小成本!必须要双方同意(都不发消息)!

状态变化:

当客户端退出,服务器端不调用close的时候,服务端进入CLOSE_WAIT状态,服务端进入FIN_WAIT2的状态。

【计算机网络】Tcp详解_第6张图片

一段时间后,客户端的FIN_WAIT2消失,服务端仍是CLOSE_WAIT状态。所以,对于服务器端,要关掉文件描述符!

调用close后,服务器端立马进入LAST_ACK状态,并发送FIN给对端,如果对端已经关闭,在经历几次重传后,服务器端也会断开连接。

主动断开的一方,要进入TIME_WAIT状态,此时立马想要重启,会失败,原因是底层连接还在,正处于TIME_WAIT状态。

  • 1、为什么要进入TIME_WAIT

    TCP协议规定,主动断开连接的一方,要等待两个MSL时间(一个报文在网络里存在的最大时间),

    • 1、让网络中的报文尽快消散,防止对新的连接产生影响。
    • 2、保证最后一个ACK让对方收到。对方如果没收到最后一个ACK,会再发送FIN。
  • 2、如果server不想等待

    //设置地址可以复用,令服务器立马重启
    setsockopt(int sockfd,int level,int optname,const void* optval,socklen_t optlen)
    参数:
    sockfd:套接字
    level:当前在哪一层(SOL_SOCKET)
    optname:(SO_REUSEADDR | SO_REUSEPORT)
    optval:1
    optlen:len
    

粘包问题

TCP没有UDP里面的报文长度字段,我们并不知道两个数据的边界,这样的问题就是粘包问题

解决:明确两个包之间的边界(上层去完成)。

TCP异常情况

进程终止/机器重启:进程终止会释放文件描述符,仍然发送FIN,和正常关闭一样(操作系统回收所有相关资源)

机器掉电/网线断开:对端认为连接还在,一旦接收端有写入操作,发现连接不在了,就会reset,服务器发送保活定时器,发送端也可reset

listen的第二个参数

设置第二个参数为1,连接服务器,一定程度后,进入SYN_RECV,即已经建立好的链接只能是两个。

TCP协议,需要在底层维护全连接队列,最大长度为:第二个参数 + 1

将没有连接到半连接队列,时间非常断。

全连接队列不能太长,也不能没有。全连接的长度不是服务器处理的长度,而是一个 “排队” 的地方.

1、会消耗过多的OS资源,不如给server使用
2、尾部等待太长。

你可能感兴趣的:(计算机网络,计算机网络,tcp/ip,网络)