机制都是在保证可靠传输可以理解为发一条消息上面显示已读未读可靠传输就是发一条消息我知道对方是否收到。

确认应答要针对数据进行编号然后才能明确应答报文实在应答那个数据应对了网络传输的“后发先至”

32位确认序号如果当前报文是一个普通的报文。

确认序号不生效但是如果当前报文是一个应答报文确认序号就表示应答的是哪个普通报文。

报文字节

由于TCP是面向字节流的编号的时候不是按照条编号而是按照字节来编号。

图中的主机A发送了100字节的数据一个TCP数据报长度是1000序号是1

应答报文中的确认序号就是1001。

应答报文可以视为只有TCP报头没有载荷。

其中的确认序号字段填写的是1001意思就是1001的数据主机B全部都收到了接下来A就要从1001开始往后发送。

B这边调用一个recv方法

第一次读取的是1111第二次读取的是2222第三次读取的是3333

每次调用recv方法就是从接收缓冲区中取走一个数据UDP的接受缓冲区相当于一个链表里面三个节点每次都以一个节点为单位进行读取这就是面向数据报。

在TCP中

TCP的接收缓冲区就i像一个数组若干个TCP数据报的载荷会一直追加到这个数组里这就是面向字节流。

在TCP报头中有6个非常重要的比特位其中第二个ACK就是表达的应答报文。

URGUrgentURG标志位占据TCP头部的第13位最左边的位用于指示紧急数据。

如果URG标志位被设置为1那么TCP包含的数据被标记为紧急数据需要被尽快传送和处理。

ACKAcknowledgmentACK标志位占据TCP头部的第14位用于确认对方已经成功接收到了之前发送的数据。

当ACK标志位被设置为1时表示这是一个包含确认信息的TCP报文。

PSHPushPSH标志位占据TCP头部的第15位用于指示接收方应该尽快将数据交给应用程序而不是等到缓冲区充满或等待定时器触发。

RSTResetRST标志位占据TCP头部的第16位用于重置连接。

如果RST标志位被设置为1它表示连接出现了异常需要立即关闭并且后续的数据传输将被终止。

SYNSynchronizeSYN标志位占据TCP头部的第17位用于建立连接。

当客户端尝试与服务器建立连接时它会将SYN标志位设置为1表示请求建立连接。

FINFinishFIN标志位占据TCP头部的第18位用于关闭连接。

当一方希望关闭连接时它会将FIN标志位设置为1表示它已经不再发送数据并且希望进行优雅的连接关闭。

在确认应答的情况下如果收到了ACK就好办但是如果没有收到呢?还需要通过其他途径来处理。

确认应答是一种很理想的状态但是数据开发的过程中很容易出现丢包的情况。

发送请求丢失

业务数据已经到了主机B反馈的ACK没有回去发送方等待了一会之后就会触发重传。

对于发送方来说无法区分是发送请求丢失还是ACK丢失因此发送方能做的就是到达一定时间超时重传。

ACK丢失的情况下进行超时重传接收方会收到两份相同的数据这个时候就会涉及到去重。

根据序列号把序列号相同的去除掉。

丢包操作还有一个超时时间超时时间具体是多少在操作系统内核是可以配置的。

这里等待的时间间隔随着时间的推移越来越大连续两次没发过去意味着当前单次丢包的概率已经相当大了很可能是网络上遇到了非常严重的事故短期内恢复不了发送的再频繁也没用。

超时重传也不会无限制的重传下去尝试几次之后仍然无法传送过去此时就会放弃重传然后尝试断开重连如果重连还没连上去就彻底放弃了。

“确认应答一定能在这个时间内返回”。

但是这个时间的长短随着网络环境的不同是有差异的。

如果超时时间设的太长会影响整体的重传效率如果超时时间设的太短有可能会频繁发送重复的包

TCP为了保证无论在任何环境下都能比较高性能的通信因此会动态计算这个最大超时时间

Linux中BSD

Unix和Windows也是如此超时以500ms为一个单位进行控制每次判定超时重发的超时时间都是500ms的整数倍。

如果重发一次之后仍然得不到应答等待

累计到一定的重传次数TCP认为网络或者对端主机出现异常强制关闭连接

建立连接-三次握手

当A给B打电话的时候打电话的时候同样要验证自己一起对方的话筒和自己的听筒是否正常

第一次握手

以上三次握手就保证A、B的听筒和话筒都是正常也就保证了通话的正常这就也是类似网络建立连接的三次握手

第一次握手客户端希望与服务器建立连接因此它首先向服务器发送一个TCP报文段其中包含SYN同步标志位。

这个SYN标志位表示客户端希望建立连接并在报文段中包含一个初始序列号ISN该序列号用于标识客户端发送的数据。

第二次握手服务器收到客户端的SYN后会确认客户端的请求。

服务器向客户端发送一个TCP报文段其中包含SYN和ACK确认标志位。

服务器也会选择自己的初始序列号ISN。

这个ACK用于确认客户端的SYN并表示服务器已经准备好建立连接。

第三次握手客户端收到服务器的SYN-ACK后会发送一个带有ACK标志位的TCP报文段给服务器。

这个ACK用于确认服务器的SYN并表示客户端也已经准备好建立连接。

同时客户端也会发送自己的初始序列号。

SYN在各自给对方发送给

为什么要合并在一起传输每次报文传输都会经过一系列的封装分用分成两个包的代价就会很大。

断开连接-四次挥手

三次握手双方各自向对方发起建立连接的请求确保双方都明确知道对已准备好连接。

四次挥手用于确保双方在终止连接之前完成数据传输并且都明确知道对方已经准备好关闭连接。

第一次挥手客户端向服务器发送FIN

客户端决定关闭连接因此向服务器发送一个TCP报文段其中包含FINFinish标志位。

则合格FIN表示客户端已经完成数据发送并请求关闭。

客户端进入FIN_WAIT1状态。

第二次挥手服务器回复ACK

服务器收到客户端的FIN后会发送一个确认ACK数据报作为响应以确认它已经收到客户端的关闭请求同时服务器进入CLOSE_WAIT状态。

第三次挥手服务器向客户端发送FIN

当服务器也决定关闭连接时它会向客户端发送一个带有FIN标志位的TCP报文段表示服务器已经完成数据发送并请求关闭连接。

服务器进入LAST_ACK状态。

第四次挥手客户端回复ACK

客户端收到服务器的FIN后会回复一个确认ACK表示客户端已收到服务器的关闭请求此时客户端进入TIME_WAIT状态等待一段时间通常是两倍的最大寿命以确保服务器收到ACK然后才最终关闭连接。

在客户端的TIME_WAIT状态结束后连接关闭。

服务器在发送FIN后等待一段时间确认客户端收到FIN的ACK之后连接终止。

四次挥手三次挥完不行呢

因为中间两次操作时机不一样ACK是收到FIN之后立即由操作系统内核返回的数据报告诉客户端收到了关闭的消息而FIN是应用程序处理完接受缓冲区的数据之后调用close方法触发的。

延时应答和捎带应答

三次握手和四次挥手中间数据传输流程三次握手四次挥手过程中TCP状态转换每个过程涉及到的socket.api

CLOSED关闭初始状态表示TCP连接未建立。

在CLOSED状态下不进行数据传输或通信。

LISTEN监听在服务器端当服务器准备好接受客户端连接请求时它会进入LISTEN状态。

服务器等待客户端的连接请求一旦收到连接请求将进入ESTABLISHED状态。

SYN_SENT同步已发送客户端在尝试与服务器建立连接时会进入SYN_SENT状态。

在这个状态下客户端已发送一个带有SYN标志的连接请求并等待服务器的确认。

SYN_RECEIVED同步已接收服务器在收到客户端的连接请求后会进入SYN_RECEIVED状态表示已接收客户端的连接请求准备好建立连接。

服务器会回复一个带有SYN和ACK标志的数据包作为确认。

ESTABLISHED已建立连接已经建立双方可以进行数据传输。

在这个状态下数据可以在客户端和服务器之间自由传输。

FIN_WAIT_1等待对方的结束请求第一阶段当一方通常是客户端决定关闭连接时它会进入FIN_WAIT_1状态并发送一个带有FIN标志的数据包表示它不再发送数据。

FIN_WAIT_2等待对方的结束请求第二阶段在FIN_WAIT_1状态之后如果对方通常是服务器也决定关闭连接它会发送一个带有FIN标志的数据包作为确认连接进入FIN_WAIT_2状态。

TIME_WAIT等待时间连接已经被双方关闭但为了确保所有的数据包都被完全传递和处理连接会进入TIME_WAIT状态一段时间。

这个状态通常持续2倍的最大报文段寿命Maximum

Segment

CLOSING关闭中表示连接的一方已经发送了FIN标志但还没有收到对方的确认所以连接进入CLOSING状态等待最后的确认。

CLOSE_WAIT等待关闭表示连接的一方已经收到对方发送的FIN标志并进入CLOSE_WAIT状态等待应用程序处理完所有数据后进行连接关闭。

LAST_ACK最后确认在一方发送了FIN标志后如果另一方也发送了FIN并进入CLOSING状态那么它会进入LAST_ACK状态等待最后的确认。

UNKNOWN未知在某些情况下连接状态可能无法明确定义或者出现异常情况时可能处于UNKNOWN状态。

四、滑动窗口效率机制

刚才我们讨论了确认应答策略对每一个发送的数据段都要给ACK确认应答收到ACK后再发下一个数据报这样会有一个很大的缺点没法送一个数据报就需要一次请确认应答才能发送下一个数据报这样会导致性能比较差发送时间增长。

提高效率的机制本质就是把等待ACK的时间重叠起来减少等待时间就相当提高效率

这里的N越大则同时批发数量就会越多传输效率就会越高但是N不是越大越好

发送一批数据会不会乱序

在传输数据的时候很有可能出现“后发先至”的问题但是TCP就会在接收缓冲区里按照序号进行排序保证顺序。

其中灰色的一块一块的区域就是一个TCP数据报白色的区域就是要批量发送的图中发送了

1001-2000

当2001ACK回到A的时候此时1001-2000这个数据就已经被对方收到了就可以发送5001-6000这个数据了。

如果出现丢包如何进行重传

如上主机A发了半天之后法案先好几个连续的1001就明白1001-2000这个数据可能丢失了接下来就会重传这个数据此处的原则就是哪条丢失就重传那条数据已经重传的数据就不需要重传不必重复传输快熟重传不是重传的有多快而是没有多余的冗余动作

滑动窗口能提高效率指的是相比于没有滑动窗口普通的确认应答。

但是如果和无可靠性的传输相比UDP效率还是要差一些。

与其说它是提高效率不如说它是在补救低效率

滑动窗口窗口越大发送速率就会越快流量控制就是针对发送速率进行制约维持可靠性。

发送速率

如果发送速率接受速率这个时候继续提高发送速率就不能提高整体效率反而会因为接收方的丢包触发多次重传反而降低效率。

接受速率如何衡量

图中圈出来的部分操作的快慢就是衡量接收速率快慢的和应用程序代码相关

流量控制就是通过解说缓冲区剩余空间大小来作为下一次发送的时候窗口大小

ACK

报文的时候会生效这个窗口大小就表示了接收缓冲区的剩余空间大小根据这个大小就可以进一步的影响到发送速率了

不是我们可以有选项也可以没有可以有一个也可以有多个这里有一个特殊的字段窗口扩大因子~窗口扩大因子可以是2可以是4可以是任何数相乘即可如果没有窗口扩大因子默认是1。

流量控制站在接收方的角度来控制发送速率但是整体的传输其实不光有发送方和接收方还有中间一系列用来转发的设备

控制A发的快慢不仅要考虑到B的接受能力1也要考虑到中间设备的转发能力

中间的设备都有几个中间的设备各个参数是啥两次传输经历的中间设备是否相同

对于拥塞控制采取的方法就是实验通过实验的方式找到一个和舍得窗口大小

刚开始按照小窗口来发送如果不丢包说明网络中间环境比较通常就可以提高发送窗口大小放大到一定程度速率已经比较快网络上就容易出现拥堵当发送方发现丢包之后就减小发送的窗口。

发送的速率不快不慢接近能承载的极限同时还可以尽量减少丢包还能适应网络环境的动态变化

流量控制

都是通过控制窗口大小来制约发送方的发送速率的在保证可靠性的前提下尽量提高一下发送的速度都能影响发送方滑动窗口大小最终的滑动窗口大小就取决于流量控制和拥塞控制的窗口的“最小值”

如果是拥塞控制的窗口大流量控制的窗口小中间的节点转发能力强接收端的代码处理的慢。

如果是拥塞控制的窗口小流量控制的窗口大中间的节点转发能力弱接收端的代码处理的快。

其中拥塞控制的窗口大小是发送方自己做实验做出来的流量控制的窗口大小是接收方通过接收缓冲区剩余空间大小通过

ACK

报文的报头返回给发送方的。

最终发送方下一次发送窗口的大小就是通过这两个值的较小值来确定的。

初始时候拥塞窗口从一个很小的数字开始指数增长~(慢开始)刚开始的时候网络环境是否拥堵我们不知道先拿一个小的速率发送是稳健的做法如果窗口大小到达阈值之后就不再指数增长了变成了线性增长。

当线性增长达到一定程度之后此时就可能丢包这个时候直接把窗口大小回归到一个特别小的窗口重复上述的指数增长

七、延时应答效率机制

也是一个用来提高效率的机制延时应答则是让窗口能大一些在流量控制中通过ACK告知对方窗口大小接收缓冲区的空余空间是多少合适

在这个等待的时间中应用程序不停的在消费接收缓冲区如果立即返回ACK可能缓冲区的剩余空间是5kb但是稍等一会应用程序就可能去走一些数据缓冲区剩余的空间可能就是50kb或者更多

这种发送方式是滑动窗口来发送的发送方是在批量发送数据所以不会对发送方等待时间造成很大影响整体影响不大

1001

在延迟应答的基础上我们发现很多情况下客户端服务器在应用层也是“一发一收”的意味着客户端给服务器说“How

are

you”那么这个时候ACK就可以搭顺风车和服务器回应的“Finethank

you”一同发给客户端

正常情况下ACK是收到请求之后内核立即返回的响应数据则是应用程序代码发送的所以他们是出于不同时机发生的不同的时机就不能把上个ACK和下一个响应报文合并。

但是上面的延时应答延时一会就可能和返回响应时间重合一起发送。

所以在延时应答和捎带应答的条件下四次挥手就可以合并变成三次挥手

九、面向字节流其他

面向字节流指的是读写载荷数据的时候是按照“字节流”的方式来读取的。

TCP数据报本身仍然是一个一个数据报这样的方法来传输的。

此时应用程序在读取数据的时候就可以很灵活的进行可以一次读取M个字节分N次来读。

如果一个TCP连接里面就只传了一个应用层数据报这个时候就不会粘包短连接、如果一个TCP连接里面传输多个应用层数据报这个时候就容易区分不清从哪到哪是一个完整的应用层数据[粘包问题]长连接

上述图文中这些数据都进入了接收缓冲区接收方也就区分不了这些数据是来自于几个应用层数据报也区分不了从哪到哪是一个应用层数据报

粘包问题解决方案

使用分隔符约定长度自定义应用层协议设计应用层协议时可以考虑使用一些高级的协议来处理粘包问题例如HTTP、WebSocket等。

这些协议通常具有消息头和消息体的结构以便更容易地解析消息。

十、异常处理其他

杀死进程释放进程PCB是访问文件描述表上对应的文件资源相当于调用close

如果挥手完成继续关机就没有问题但是如果挥手没有结束就直接关机对端会重传FIN若干次当任没有回应也就放弃单方面解除。

程序奔溃

和上面差不多的程序正常关闭还是异常奔溃都会释放PCB都会释放文件描述表

也还是会四次挥手虽然进程没了但是本身TCP连接也是内核负责的内核任然会继续完成后续需的挥手操作

主机掉电突然断电

接收方断电对方尝试发送数据发现没有ACK尝试重传几次后没有ACK发送方尝试重新建立连接如果还是建立不成功认为当前网络出现严重问题也自然的放弃。

发送方断电接收方就等待发送方发送数据由于发送方掉电这个数据发不过来接收方不知道是对方没发还是对方出了问题如果接收方一段时间没有接收到数据就会定期给发送方发送心跳包接收方给发送方发送一个特殊的报文ping对方返回一个特殊的报文pong如果这个东西有了就认为对方是正常的状态如果

ping

UDP对于可靠性传输要求不高但是对于性能要求很高同一个机房内部的主机之间通信网络环境简单宽带充裕并且又希望主机间通信能够足够快如果是需要进行

“广播”