【网络】传输层TCP/UDP，3次握手、4次挥手，超时重传，滑动窗口，流量控制，拥塞控制

传输层

1、知名端口号。ftp21、ssh22、telnet23、http80、https443。
2、netstat -nltp 查看网络状态。

UDP

如何做到封装解包？向上分用？

添加定长报头，将报头与有效载荷分离，根据你的目的端口号给你交付给应用层对应进程。

• 报文结构里的UDP长度指整个报文的长度。

UDP特点：

1. 无连接，知道对端的IP+端口号就可直接传输，不用连接。
2. 不可靠，没有确认机制，不会自动重发，如果因为网络故障无法发送给对方，UDP协议不会给应用层返回错误信息。
3. 面向数据包的，不能灵活控制读写数据的次数和数量。

UDP缓冲区：

1. UDP没有真正的发送缓冲区，调用sendto会直接交给内核，由内核将数据传给网络层协议进行后续的传输工作。
2. UDP有接收缓冲区，但是接收缓冲区不能保证收到的UDP报文的顺序和发送UDP报文的顺序相同，如果缓冲区满了，再发送的报文就被丢弃。
3. 注意：UDP协议首部中有一个16位UDP最大长度，也就是说UDP能送达的报文有大小限制为64k。

TCP

如何做到封装解包？向上分用？

4位首部长度，报头的标准长度为20字节，根据这20字节将报头与有效载荷分离，根据你的目的端口号给你交付给应用层对应进程。

TCP特点

1. 建立连接两端才可以通信。
2. 可靠传输。
3. 面向字节流。

• 因为TCP是保证可靠性，最核心机制：基于序号和确认应答机制。
• 32位序号的作用就是保证按序到达。
• 确认序号是历史上对确认报文的序号+1，通过确认序号就知道我发的那条报文被收到了。如果收到确认序号，则确认序号之前的报文都被收到了，下次就从确认序号的值开始发。
• TCP是全双工通信信道，一个报文既可以携带要发的数据，也可能携带对历史报文的确定，所以设计了两个字段。

16位窗口大小

TCP协议是自带发送和接受缓冲区的，write和read与其叫发送接受接口不如叫拷贝，应用层send数据包不是直接发送到网络上，而是把数据拷贝到了发送缓冲区，由OS给你决定什么时候发，发多少，接受时也同样是从接收缓冲区里读数据，而不是直接从网络上。
这么做可以提高应用层效率，应用层把数据交给传输层TCP，就不管了，只有OS中TCP知道如何发，什么时候发，发多少，出错了怎么办等细节问题，因为TCP是传输控制协议。有了缓冲区，将应用层和传输层进行了解耦，可以说是决策和执行进行了解耦，应用层只管把数据拷贝给你和直接从缓冲区拿数据，不关心你怎么发和收的，而TCP只管把应用层给我的数据发出去，和把接受的数据放着等你上层来拿。
16位窗口大小就是我自己的接受缓冲区的剩余空间。

6个标志位

ACK：确认报文 。
SYN：连接建立请求，一旦发送SYN请求就要三次握手。
RST：重置异常连接 。
PSH：告知对方你的缓冲区满了快让应用层来读。
URG：紧急数据要被优先处理。
FIN：四次挥手，断开连接。

超时重传

超时重传是TCP协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。
对方一直不应答累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接。

• 数据包已经抵达，但是ACK丢了？没事部分ACK丢了不要紧，通过后续收到的ACK进行确认即可，因为确认应答定义是这个ACK之前的所有都收到了。
• 数据包丢了咋办？发送端一直收到最小段接收端收到的ACK应答，当连续收到3次同样的ACK就会触发快重传，当你发送端重新发送该报文且接收端收到后则从最大段接收到的报文，给你发ACK应答。

为什么3次握手

1、确认双方主机是否健康，验证全双工通信，双方都有收发能力的最小次数
2、SYN洪水恶意攻击

为什么4次挥手

1、双方达成连接都应断开的共识
2、协商断开连接的最小次数

TCP 三次握手四次挥手过程

三次握手过程：握手前客户端和服务端都分别创建好套接字，并且服务端要进行bind绑定和listen监听。第一次握手：客户端connect后，向服务器端发送连接请求报文SYN，进入SYN-SENT状态。第二次握手：服务器端收到连接请求报文后，如果同意accept，发送应答SYN+ACK，进入SYN-RCVD状态。第三次握手：connect返回成功，客户端收到应答，最后向服务器端发送确认报文ACK，进入ESTABLISHED状态，服务端的accept也成功返回，也进入ESTABLISHED状态。此时成功建立长连接。 四次挥手过程：首先第一次挥手：客户端调用close()，认为数据发送完毕，需要向服务器端发送连接释放请求FIN，并进入FIN_WAIT_1状态。第二次挥手：服务器收到连接释放请求，然后发送ACK包，进入CLOSE-WAIT状态，此时表明客户端到服务器端的连接已经释放，不再接受客户端的数据。因为TCP是全双工的，所以服务器仍可以发送数据。第三次挥手：当服务器端数据发送完毕，向客户端发送连接释放请求FIN，进入LAST-ACK状态。第四次挥手：客户端收到连接释放请求，向服务器端发送确认应答报文ACK，此时客户端进入TIME-WAIT状态，持续2倍的MSL（最长报文段寿命），若期间没有收到服务器端的数据报文，进入CLOSED状态。服务器端收到确认应答后，也进入CLOSED状态。

TCP 和 UDP 的使用场景

UDP：直播、语音、视频、游戏、广播。TCP：转账、邮件、登陆、文件、身份信息、重要内容 。UDP的优点是快，没有TCP各种机制，少了很多首部信息和重复确认的过程，节省了大量的网络资源。缺点是不可靠不稳定，只管数据的发送不管过程和结果，网络不好的时候很容易造成数据丢失。又因为网络不好的时候不会影响到主机数据报的发送速率，这对很多实时的应用程序很重要，因为像语音通话、视频会议等要求源主机要以恒定的速率发送数据报，允许网络不好的时候丢失一些数据，但不允许太大的延迟。DNS和ARP协议也是基于UDP实现的，要求快速获取IP、MAC地址，如果基于TCP那么对整个因特网的资源占用过大且速度慢。还有游戏应用程序也是通过UDP来传输报文段，允许出现丢帧导致的卡顿，但是对游戏的整体体验不会产生严重的影响。所以UDP在语音、视频、寻址、游戏、广播方面有很好的应用前景，实时性高，允许部分的数据丢失。 TCP的优点是面向连接提供可靠交付，即对数据有保证、无差错的进行运输。当需要数据准确无误的运输给对方时，如浏览器中需要获取服务器资源使用的HTTP/HTTPS协议，需要保证文件准确、无差错，邮件服务器中使用的SMTP协议，保证邮件内容准确无误的传递给对方，或者是大型应用程序文件，这些都要保证文件的准确、无差错的运输给对方，所以一定要基于TCP来运输，而不是UDP。 加分回答 UDP的应用场景是根据它的部分特性决定的，如下： 面向无连接 尽最大努力交付 面向报文一对多 TCP的应用场景是根据它的部分特性决定的，如下： 面向连接 单播，一对一 可靠交付（确认机制、重传机制、流量控制、拥塞控制等）

说说 CLOSE_WT

在TCP四次挥手阶段，当对方提出连接释放请求时，自身给予响应ACK确认应答，但是TCP连接是全双工的，也需要自身发送连接释放请求，即FIN。但是自身并没有立即发送FIN，进入CLOSE_WT状态。 产生CLOSE_WT的原因一般是对方关闭了连接，但是自身还在读取数据或者传输数据，没有关闭连接。需要查看代码是否书写规范，是否向对方发送了FIN，一般是出现CLOSE_WT的一方出现问题。

说说 TIME_WT

TCP连接第四次挥手结束时，主动发起连接释放请求的一方进入TIME_WT状态，此时主动发起连接释放请求的一方会等待2MSL（最大报文生存期）才会回到初始状态CLOSED。
为什么要是2MSL？
1、尽量保证历史发送的网络数据都在网络中消散了（一来一回）
2、尽量保证最后一次ACK被对方收到，如果对方没有收到，则在2MSL内可以重新发送FIN，当我又收到FIN说明最后一次的ACK对方没有收到。

滑动窗口

是什么：滑动窗口是发送缓冲区的一部分。
为什么：如果数据包的发送和确认应答只能串行的发一条确认一条，那效率太低，可以一次发很多条，只是暂时不用等到确认才能发下一条，但是迟早是要收到ACK的，虽迟但到。
怎么办：发送缓冲区分为3部分，已发送且收到确认，已发送的和可以发送的但是未收到确认，这一段就是滑动窗口部分，还有就是没有发送的。滑动窗口的大小与对端16位窗口大小强相关，也就是对方的接受缓冲区的剩余大小。我发送的数据包收到ACK了滑动窗口就更新start左边去掉这一段，如果收到对端发送他的剩余接受缓冲区大小时，就更新滑动窗口右边end。

流量控制

一般都希望数据能传输得越快越好，但是如果发送方把数据发送得过快，接收方可能就来不及接受到所有的数据，中间可能会丢失数据报。而流量控制就是让发送方的发送速率不要过快，让接收方来得及接收所有的数据，利用滑动窗口这个机制可以很方便的实现在TCP连接上控制对方发送数据报的速率。

拥塞控制

滑动窗口和流量控制是针对两台主机之间的数据传输健康，而拥塞控制是针对整个网络环境的。少量报文丢失可能是主机原因，大量的丢失可能就是网络原因。此时不能大量重传，那是雪上加霜，应该让所有主机都等一等。拥塞控制就是防止太多数据挤入网络造成网络负载过大，引起阻塞网络效率降低。拥塞控制一般使用慢启动机制，一开始允许发少量数据探探路，如果网络情况不错就指数增长，后面开始线性增长，当超过拥塞阙值后，立刻将拥塞窗口设为1，阙值减少一半。

延迟应答 捎带应答

延迟应答: 提高效率，接收缓冲区为1M，当你收到500k数据，立即就应答，则你的窗口大小为500k，但可能马上上层就取走了，你延迟一会应答，窗口大小又是1M了。
捎带应答: 我给你应答ACK的时候，也可以给报文携带有效数据，比如三次握手的第二次，SYN+ACK就是捎带应答。

TCP可靠性

校验和、序列号按序到达、确认应答、超时重传、连接管理、流量控制、拥塞控制

TCP提高性能

滑动窗口、快重传、延迟应答、捎带应答

粘包问题

让应用层去解决的
TCP是面向字节流的，报文之间没有边界，需要在应用层控制
1、定长、
2、特殊字符http的\n空行等、
3、自描述字段http中有content-length
UDP没有粘包问题，因为它是面向数据包的，而且它的报文中有一个16位UDP总长度，去除报头的8字节剩下的都是有效载荷。

UDP 怎么样可以实现可靠的传输？

在应用层实现可靠性。参考TCP协议呗。
引入序列号保证数据顺序。
引入确认应答，保证对端收到数据。
引入超时重传，隔一段时间没有收到应答就重传。
连接管理机制，三次握手，四次挥手。
流量控制、拥塞控制，动态调整数据的传送效率，保证网路负载健康。
而且需要根据实际情况设计，TCP太重。

listen第二个参数

第二个参数+1表示在tcp层建立正常连接的个数（established状态，但是应用层还没accept拿走），维护在一个全连接队伍中。超过的第二个参数+1的连接就是SYN_RECV状态。

---

⭐感谢阅读，我们下期再见
如有错 欢迎提出一起交流