2UDP

UDP是面向报文的。

UDP在发送数据时会将数据划分为一个个报文既不合并也不分拆每个报文都有自己的边界。

这意味着在接收端可以轻松地将每个报文视为独立的消息。

这有助于接收端明确地识别每个消息的开始和结束。

UDP报文格式

用户UDP由两部分组成分别是首部数据部分。

首部包括了源端口、目标端口、长度以及校验和这四项是八字节。

包括源IP地址、目标IP地址、UDP长度这些是IP首部可以称伪首部。

每一部分如下所示

Protocol常用于需要高性能、低延迟和快速数据传输的场景尤其是在网络应用中需要处理实时性要求较高、可容忍一定数据丢失的情况。

以下是一些常见的UDP使用场景

实时多媒体流

UDP适用于音频和视频流传输如实时音频和视频通话、音视频会议、在线游戏的语音通信等。

在这些场景中速度和低延迟比数据的100%可靠性更为重要。

DNS解析

域名系统DNS通常使用UDP来查询域名解析因为DNS查询需要快速的响应时间而且可以容忍一些数据包的丢失。

网络广播和多播

UDP支持广播和多播通信这使得它在需要将数据广播到多个接收者的场景中非常有用如视频直播和网络广播。

实时定位服务

实时定位和地理位置服务如GPS定位使用UDP来快速传递位置信息以确保地理位置信息的及时性。

传感器数据

UDP适用于传感器网络其中传感器数据需要快速传输并及时处理但不一定需要100%的数据可靠性。

网络游戏

在在线游戏中UDP通常用于快速传输游戏状态和玩家输入因为延迟是游戏性能的关键因素。

TCP

每个TCP数据包都包含一个序号它表示发送端发送的字节流的第一个字节的序列号。

接收端使用序号来将TCP数据包按顺序重新组装以确保数据的顺序交付。

如果数据包丢失或乱序到达接收端可以使用序号来重组数据。

确认号Acknowledgment

确认号字段表示接收端期望接收的下一个字节的序列号。

它指示了接收端已成功接收并准备好接收序号为确认号的字节之后的数据。

发送端会根据确认号来知道哪些数据已经被接收哪些数据还需要重传。

如果发送端收到确认号它会知道接收端已成功接收数据并可以继续发送下一批数据。

第一次握手SYNSeqX(序列号)

客户端发送一个带有SYN同步序列编号标志的TCP数据包给服务器

数据包中包含一个初始序列号SeqX

这个数据包中包含了SYN、ACK标志表示服务器已经接收了客户端的请求并准备好建立连接。

服务器也会分配一个自己的初始序列号SeqY,来表示服务器发送的数据初始序列号

同时发送AckX1表示服务器端下一个期望接收到的Seq序列号为SeqX1

第三次握手ACKAckY1,SeqX1

接收到Seq后返回确认信息AckY1,下一个期望接收到的序列号为Y1

服务器接收到客户端的确认后进入ESTABLISHED状态而客户端也进入ESTABLISHED状态。

1第一次挥手客户端发送FIN

客户端首先决定关闭连接他发送一个数据包TCP其中包含FIN标志位这个FIN告诉服务端自己没有多余的数据要发送了但是仍然可以接收数据同时包含Sequ自己进入FIN-WAIT关闭等待状态

2第二次挥手服务端发送ACK服务端接收到客户端的FIN后需要里面回复一条带有ACK的确认位由于收到的Sequ,所以返回ACK以及Acku1同时自己也发送一个seqv到客户端自己进入CLOSE-WAIT

关闭等待状态

3第三次挥手服务端发送FIN服务端准备关闭连接了所以主动向客户端发送FIN请求其中发送FIN、ACK同时还发送自己的Seqw等待确认Acku1对上一条的回复此时服务端进入LAST-ACK最后确认状态

第四次挥手客户端发送ACK客户端接收到消息后发送一个ACK以进行确认同时发送Sequ1对上一条Ack进行回复ackw1对上一条Seq进行确认。

第一次挥手A

这个题重点在于回答三次握手和两次握手的区别。

四次握手或者更多你就可以直接说如果三次握手能够解决问题四次、五次更多的连接就是浪费资源没必要

RFC

两次握手场景下客户端先后发送了两端连接请求SeqX和SeqY,那由于SeqY是后发送的所以客户端更希望自己收到的是AckY1,但是SeqX会先到达服务端服务端会根据SYN和SeqX,向客户端回消息AckX1,此时客户端会认为连接已经建立两次连接嘛。

所以开始向客户端发送消息。

客户端发现自己收到了AckY1知道不是自己期望的所以会要求连接中断。

两次握手场景中服务端发送了ACK和AckX1后就开始发送数据了此时服务端不知道客户端有没有收到自己的确认消息。

不能维持双向连接的基本需求。

四次挥手时报文丢失

客户端调用close函数就会向服务端发送FIN报文试图与服务端断开连接此时客户端进入了Fin_WAIT状态。

如果客户端一直没有收到Ack应答报文就会触发超时重传机制有最大次数限制。

超过最大次数就不再发送报文直接进入close状态。

2.第二次挥手报文丢失

当接收到客户端的FIN报文就会先回应一个ack报文此时服务端进入了CLOS_WAIT状态。

3.第三次挥手报文丢失

服务器发送带有FIN标志的数据包以请求关闭连接但是数据包丢失。

服务器需要等待客户端的确认ACK然后重传FIN以开始新的挥手过程。

4.第四次挥手报文丢失

客户端接收到服务器的FIN后发送带有ACK标志的数据包但该数据包丢失

客户端可能需要等待服务器的FIN重传然后重新发送ACK以继续挥手过程。

挥手之后为什么需要TIME_WAIT状态

保证双方能够正常关闭如果没有TIME_WAIT状态的话客户端最后一次发送ack应答报文后就进入了close阶段。

如果服务端没有收到ack报文的话就会重传FIN报文而此时客户端已经close了就会返回一个RST错误报文。

而有了TIME_WAIT状态的话客户端并不会着急关闭而是等待了2MSL再关闭这样的话就算重传的fin报文也能正确响应保证了服务端的正确关闭

2防止旧连接的数据干扰新连接假设没有TIME_WAIT状态那么在关闭连接前有个报文被延迟了。

关闭后又重新建立了相同四元组的连接此时前一个被延迟的数据包到达了(没有到达最大生存时间)并且正好在接收窗口内那么服务端就会错误接收使得数据混乱。

而TIME_WAIT就是帮助客户端和服务端删除两边的一个历史都被正常丢弃不干扰新的连接

为什么第四次挥手客户端需要等待

服务器之间的通信而设计的。

当我们使用浏览器浏览网页的时候我们网页就是通过

HTTP

协议注HTTP3.0是基于UDP的HTTP2.0和HTTP1.0是基于TCP协议的

HTTP

协议是”无状态”的协议它无法记录客户端用户的状态一般我们都是通过

Session

HTTP是一种不安全的协议传输的数据在传输过程中是明文可见的。

这意味着敏感信息如用户名、密码、信用卡号等可能会在传输过程中被攻击者拦截和窃取。

端口号

HTTP默认使用端口号80来进行通信。

URL以http://开头

HTTPSHTTP

Security来加密传输的数据确保数据在传输过程中是加密的难以被窃取。

端口号

HTTPS默认使用端口号443来进行通信。

这个端口号是经过加密的与HTTP的80端口有区别。

URL以https://开头

明文的、文本协议而不是2进制协议人可以看懂里面的聂荣消息是一来一回的。

即客户端发起一个TCP连接在连接上面发一个HTTP

Response然后连接关闭。

每来一个请求久开一个连接请求完了久关闭连接。

根据上面的特性其实HTTP最典型的问题就是性能问题连接的建立和关闭都是耗时的。

对于一个网页来说除了页面本身的请求页面里的JS、CSS、img资源都是一个个HTTP请求。

一个页面有十几个资源甚至是几十个都是很常见的。

这种连接关闭是非常消耗时间的。

HTTP1.1引入了持久连接允许在一个连接上处理多个请求和响应降低了建立和关闭连接的开销提高了性能。

引入了管道的机制没在一个请求发出去后响应没有收到之前就可以发送下一个再下一个请求提高了同一个TCP连接上的请求处理效率。

HTTP

引入了主机头部使得一台服务器可以托管多个域名从而支持虚拟主机。