asp网站服务建设论文,游戏开发公司定制游戏,织梦网站数据库库直接上传的 没有后台备份 需要怎么还原,WordPress修改_文章目录TCP UDP协议1. 概述2. 端口号 复用 分用3. TCP3.1 TCP首部格式3.2 建立连接-三次握手3.3 释放连接-四次挥手3.4 TCP流量控制3.5 TCP拥塞控制3.6 TCP可靠传输的实现3.7 TCP超时重传4. UDP5.TCP与UDP的区别TCP UDP协议
1. 概述
TCP、UDP协议是TCP/IP体系结构传输层中的…
文章目录TCP UDP协议1. 概述2. 端口号 复用 分用3. TCP3.1 TCP首部格式3.2 建立连接-三次握手3.3 释放连接-四次挥手3.4 TCP流量控制3.5 TCP拥塞控制3.6 TCP可靠传输的实现3.7 TCP超时重传4. UDP5.TCP与UDP的区别TCP UDP协议
1. 概述
TCP、UDP协议是TCP/IP体系结构传输层中的两个重要协议。
如图所示为计算机网络四层模型 **IP协议**是网际层中的核心协议它可以互联不同的网络接口并向其上层提供无连接、不可靠的数据传输服务。
TCP/IP体系结构的应用层中包含许大量的应用层协议其中有些应用层协议需要使用可靠传输服务例如浏览网页、传输文件等这些数据一旦传输失败会造成无法挽回的危害。而有些则需要使用不可靠传输服务例如音视频通话等少量的数据传输错误并不会对播放造成大影响。
由于应用层需要使用可靠和不可靠两种传输服务但IP协议只能提供不可靠传输服务于是就需要传输层来提供可靠/不可靠的传输服务。
其中TCP提供可靠性传输服务UDP提供不可靠传输服务。
TCP Transmission Control Protocol传输控制协议为上层提供的是面向连接的可靠的数据传输服务。使用TCP通信的双方在传送数据之前必须首先建立TCP连接逻辑连接而非物理连接。数据传输结束后必须要释放TCP连接。TCP为了实现可靠传输就必须使用很多措施例如TCP连接管理、确认机制、超时重传、流量控制、拥塞控制等。TCP的实现复杂报文首部较大占用处理机资源比较多。
UDP User Datagram Protocol用户数据报协议为其上层提供的是无连接的不可靠的数据传输服务因此不需要实现可靠传输的各种机制。使用UDP通信的双方在传送数据之前不需要建立连接。UDP的实现简单用户数据报首部比较小。
2. 端口号 复用 分用
端口号 运行在计算机上的进程使用进程标识符PID来区分但是因特网上的计算机使用操作系统复杂不同的操作系统又有不同格式的进程标识符为了使运行在不同操作系统的计算机的应用进程之间能够进行通信就必须使用统一的方法对TCP/IP体系的应用进程进行标识而这个标识方法就是**端口号**运输层使用端口号来区分应用层的不同应用进程。端口号只具有本地意义即端口号只是为了标识本计算机应用进程在因特网中不同的计算机中的相同端口没有联系你电脑上的8080端口跟我电脑上的8080端口一点关系没有。
发送方的复用 应用层报文经过传输层TCP协议进行封装称为TCP复用。应用层报文经过传输层UDP协议封装称为UDP复用。传输层的报文经过网络层IP协议的封装称为IP复用
接收方的分用网络层使用IP协议解析接受的IP数据报称为IP分用。传输层使用TCP协议解析接受的TCP数据报称为TCP分用。传输层使用UDP协议解析接受的UDP数据报称为UDP分用。
3. TCP
3.1 TCP首部格式
TCP协议处于传输层它向上层应用层提供面向连接的可靠传输服务为了实现可靠传输采用了**面向字节流**的方式。
TCP在发送数据时从发送缓存中取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后在发送给下层。一个TCP报文段由首部和数据载荷两部分组成TCP实现连接管理、确认机制、超时重传、流量控制、拥塞控制这些功能都体现在它首部中各字段的作用。
TCP首部由两部分构成 20字节的固定首部和最大40字节的扩展首部。也就是说一个TCP首部的字节数在20~60字节之间。 源端口 16比特即两字节写入源端口号用于标识发送该TCP报文段的应用进程。
目的端口 16比特即两字节写入目的端口号用于标识接受该TCP报文段的应用进程。
假如我们使用web服务127.0.0.1:8080远程访问MySQL服务器48.104.60.218:3306源端口就是我们自己的IP地址中的端口8080目的端口就是MySQL服务器的IP地址中的端口3306。
接下来看看与TCP实现可靠性传输有关的三个字段 序号、确认号、ACK。
序号 占32比特取值范围[0, 2^32 - 1]序号增加到最后一个后下一个序号就又回到0。序号的值用来指出本TCP报文段**数据载荷**第一个字节的序号。如图所示首部的序号即为数据载荷第一个字节的序号122。 确认号 占32比特取值范围[0, 2^32 - 1]确认好增加到最后一个后下一个确认好又回到0。确认号的值用于指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号同时也是对之前收到的所有数据的确认。可以这样理解若确认号为n则代表之前已经成功接收到序号为n-1的报文段下一次期望收到序号为n的报文段。只有ACK标识的值为1时确认号字段才有效。
ACK 确标志位取值为1时确认号才有效取值为0时确认号无效。TCP规定连接建立后所有的TCP报文段都必须把ACK置为1。
如图客户端向服务端发送一个TCP数据报序号为200代表此数据报的数据载荷部分的第一个字节的序号为200。确认号为800代表客户端已经收到服务端发送的序号为799号以及之前的数据报现在想要序号为800的数据报。ACK的值为1保证确认号有效。数据载荷长度代表此次传输的字节数。也就是说此次传输的数据载荷部分的序号为 200 - 300。 数据偏移 占4比特并以4字节为单位。用于指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远。这个字段实际上是指出了TCP报文段的首部有多少个字节。同时它的值是首部字节数除以4的。首部的字节数范围为20 ~ 60所以数据偏移字段的值范围为 5~15即 0101到1111。
保留 占6比特保留以后使用。目前值为0。
窗口 占16比特以字节为单位。指出发送本报文段的一方的接收窗口。窗口值作为接收方让发送方设置其发送窗口的依据。这是以接收方的接受能力来控制发送方的发送能力称为流量控制。需要注意的是发送窗口的大小还取决于拥塞窗口的大小也就是从接收窗口和拥塞窗口中取最小值。
校验和 占16比特用于检查整个TCP报文段在传输过程中是否出现了误码。
紧急指针 占16比特以字节为单位用来指明紧急数据的长度。当发送方有紧急数据时可将紧急数据插队到发送缓存的最前面并立刻封装到一个TCP报文中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据紧急数据之后是普通数据。
SYN 同步标志位在TCP连接建立时用来同步序号。TCP规定SYN值为1时代表正在建立连接此报文段不能携带数据。
FIN 终止标志位用于释放TCP连接。TCP规定FIN值为1时代表正在释放连接此报文段不能携带数据。
RST 复位标志位用于复位TCP连接。当RST为1时表示TCP连接出现了异常此时必须先断开连接再重新建立连接。RST还用来拒绝非法报文段或拒绝TCP连接。
PSH 推送标志位用来实现推送操作。当接受方收到该标志位为1的报文段会尽快上交应用进程而不必等到接收缓存都填满后再向上交付。
URG 紧急标志位与紧急指针字段共同实现紧急操作。紧急标志位URG为1时紧急指针有效为0时紧急指针无效。
选项 选项中的字段都是可选值扩展功能。选项的字节数可变
填充 由于选项的字节数可变那就使用填充字段确保报文段首部能被4整除。假如选项有3字节那么填充就只有1个字节。
为什么一定要确保首部字节数要能被4整除因为数据偏移字段的值是首部字节数除以4。 3.2 建立连接-三次握手
TCP是面向连接的协议它基于运输连接来传送TCP报文段。TCP运输连接的建立和释放是每一次面向娘连接的通信中必不可少的过程。
TCP运输连接分为以下三个阶段
通过三次握手建立TCP连接进行数据传输通过四次挥手断开TCP连接
先来介绍一下TCP连接的建立 三报文握手
最初TCP客户端与TCP服务端的TCP进程都处于关闭状态即CLOSED。
一开始TCP服务端先创建TCP传输控制块用于存储TCP连接中的以下重要信息例如TCP连接表、指向发送和接受缓存的指针、指向重传队列的指针…TCP服务端创建传输控制块后就进入监听状态LISTEN等待接受TCP客户端的连接请求。
TCP客户端在发起连接请求之前也要创建传输控制块之后发起连接请求。 第一次握手
TCP客户端进程向TCP服务端进程发送TCP连接请求报文段并进入同步已发送状态SYN-SEND。
此连接请求报文段首部中的值 SYN 1表明这是一个TCP连接请求报文段。同时规定此时的报文段不能携带数据。 序号(seq) 初始值x 第二次握手
TCP服务端接收到请求连接报文后如果同意连接会向TCP客户端发送 连接请求确认报文段并进入同步已接受状态SYN-RCVD。
该报文段首部中的值 SYN 1表明现在正在进行TCP连接。同时规定此时的报文段不能携带数据。 ACK 使确认号生效。 确认号(ack) 由于客户端发送的序号为x那么确认号就是x1代表“我已经收到序号为x以及之前的数据了你下次给我发x1吧”。 序号(seq) 初始值y。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4nZdkdLy-1678504984186)(assets/image-20230308181233-f7ep57n.png)]
第三次握手
TCP客户端收到连接请求确认报文段后还需要向TCP服务端进程发送一个**普通的TCP确认报文段并进入连接已建立状态ESTABLISHED。由于是一个普通**的连接建立报文段所以它的SYN字段值并不为1所以这个报文段可以携带数据但是它不携带数据。
TCP规定SYN为1的报文段不能携带数据报文段发送时消耗一个序号。SYN不为1的报文段可以携带数据如果不携带数据不消耗序号
该报文段的首部值
ACK 1保证确认位可用。序号(seq) x1因为TCP服务端上次发的报文中的确认号为x1。由于SYN值不为1并且没有携带数据故x1这个序号下次还能用也就是建立连接后还可以再使用一次x1这个序号。确认号(ack) y1因为TCP服务端上次发送的报文段的序号为y所以我们这次发送y1表示我们已经接收到了序号y以及之前的数据下次我们想要序号为y1的数据。 当TCP服务端接收到TCP客户端第二次报文时服务端也进入连接已建立状态ESTABLISHED。 现在双方都已进入连接建立状态可以根据已经建立好的TCP连接进行可靠的数据传输。 那么为什么建立TCP连接一定需要三次呢为什么不能是两次为什么不能使用两次报文握手建立连接呢 接下来看看两报文握手会出现的问题
TCP客户端发出请求连接报文但是因为网络问题长时间停滞在网络中于是触发超时重传机制TCP客户端重新发起TCP连接请求报文段这次成功建立连接。之后便是数据的传输最后数据传输完成服务端与客户端断开连接。 断开连接后突然上次因为网络问题滞后的TCP连接请求发送到了TCP服务端服务端以为客户端想要再次建立TCP连接于是服务端进入监听LISTEN状态并向客户端发送连接请求确认报文但是客户端此时为关闭状态对连接请求确认报文不予理睬于是服务端一直处于监听状态并发送连接请求确认报文。这就造成了TCP服务端资源的浪费。 综上所述采用三报文握手而不是两报文握手是为了防止已失效的连接请求报文段突然传送到了TCP服务端因而导致的错误。
3.3 释放连接-四次挥手
TCP通过四次挥手来结束TCP的连接。
在断开连接之前客户端与服务端都处于连接已建立状态ESTABLISHED。
第一次挥手
TCP客户端会发送TCP连接释放报文段进入终止等待1状态FIN-WAIT-1。TCP连接释放报文段的字段值为
FIN 1代表此时正在释放TCP连接此报文段不能携带数据。ACK 使确认号生效。seq(序号) u代表此报文段的数据载荷的第一个字节的序号为u。ack(确认号) v代表已经收到序号为v-1的数据下次想要序号为v的数据。
第二次挥手
服务端接收到客户端发送的TCP连接释放报文段后会向客户端发送一个普通的TCP确认报文段并进入关闭等待状态CLOSE-WAIT。
此时的TCP连接进入了半关闭状态因为客户端到服务端的TCP连接进入关闭状态因为客户端已经没有数据要发送了但是服务端到客户端的TCP连接通道还没关闭因为服务端要继续发送那些还未发送完毕的数据。
此报文段的字段值
ACK 1保证确认号有效序号(seq) v代表此报文段的数据载荷的第一个字节的序号为v。确认号(ack) u1代表已经收到客户端发送的第u条数据下次想要u1。
TCP客户端收到TCP服务端发送的TCP确认报文段后就会进入终止等待2状态FIN-WAIT2。
第三次挥手
当TCP服务端所有剩余数据发送完毕后TCP服务端会发送TCP连接释放报文段并进入最后确认状态LAST-ACK。
该报文段的字段
FIN 1表示正在释放连接。ACK 1保证确认号有效。序号(seq) w为什么不是v1因为第二次挥手之后可能传输了其他剩余数据报。确认号(ack) u1。为什么是u1不是又发送了剩余数据吗因为剩余数据报只是服务端向客户端发送客户端向服务端的TCP连接通道已经断开。
第四次挥手
收到服务端发送的TCP连接释放报文段后客户端发送普通的确认报文段之后进入时间等待状态TIME-WAIT。
收到该报文段后服务端关闭。处于时间等待状态2MSL(2mins)后客户端TCP连接关闭。
该报文字段值
ACK 1保证确认号有效序号(seq) u1确认号(ack) w1
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u0RBO0Rt-1678504984188)(assets/image-20230309151435-5c57p7p.png)] 为什么客户端还要等待两分钟再关闭TCP连接呢 假如不进行等待而直接关闭也就是客户端发送第四次挥手之后立即关闭TCP连接。那么如果最后一个确认报文丢失此时客户端已经关闭但服务端还在等待最后的确认保报文一直没等到就会触发超时重传机制发送第三次挥手报文但是客户端已经关闭那么服务端就会一直发送第三次挥手报文非常浪费资源。而等待两分钟就可以解决这个问题客户端有足够时间等待服务端发送的超时重传报文。
至此四报文挥手过程完毕。
接下来看看保活计时器
在客户端与服务端建立连接后如果客户端出现故障应当有措施让服务端主动断开连接而不是一直等待下去。这时就要使用到保活计时器。
TCP服务器进程每收到一次TCP客户进程的数据就重新设置并启动保活计时器(定时2小时)。若2小时内没接收到TCP客户端发送的数据则当保活计时器到时后TCP服务器向TCP客户端发送一个探测报文段以后则每75秒发送一次若连续10个报文段都无响应TCP服务端主动断开TCP连接。
3.4 TCP流量控制
为什么需要流量控制一般来说我们更加希望传输速度越快越好但是如果发送方发送数据的速度过快会导致接受方来不及接收这就会造成数据的丢失。
所以流量控制就是为了让发送方发送的速率不要太快要让接受方来得及接收。
TCP的流量控制是通过滑动窗口来实现的。如果此时A向B传输数据在传输数据前B告诉A我的接收窗口rwnd400(receiver window)。这表示 发送方A的发送窗口不能超过接受方B的接收窗口的值也就是400字节。
假如B最初的接收窗口大小为400那么A可以发送400字节的数据。B接收400字节数据并发送确认后这400字节的数据会先从A的发送缓存中删除。现在A成功向B发送了400字节的数据但是B的接收缓存没多少空间了于是B对A说我的接收窗口为rwnd300。这表示发送方A的发送窗口不能超过300字节。就这样如果发送后B的发送缓存还没腾出空间会继续减小接收窗口直到B的发送缓存没有空间这时B向A发送的rwnd0即零窗口通知代表不要再发送数据了等我腾出空间再说吧。 如果A发送的数据丢失怎么办呢 A给B发送消息如果数据丢失并不会影响A后续数据的发送B发送的ack消息会告诉A哪些数据还没有发送到时A重新发送即可。 如果B发送的rwnd丢失怎么办呢 如果B发送给A的rwnd丢失A一直在等待B发送的窗口通知(rwnd)以便设置自己的发送窗口而主机B以为A已经接收到窗口通知他就一直等待A发送的数据这就会造成死锁的局面。为了解决这个问题TCP为每一个连接设置一个持续定时器。
如果B给A发送零窗口通知持续计时器会重新计时当持续计时器超时时证明已经很久没有收到零窗口通知了A就给B发送一个探测报文B接收该报文后将自己的接收窗口值发送给A如果此值为0则持续计时器重新计时如果此值为其他值A将其发送窗口大小设置为此值。于是死锁问题得以解决。
3.5 TCP拥塞控制
拥塞 对网络中某一资源的需求超过了该资源所能提供的可用部分网络性能就要变坏。这种情况叫做拥塞congestion。
若出现拥塞而不进行控制整个网络的吞吐量将随输入负荷的增大而下降。
TCP对拥塞控制提供了四种算法
慢开始slow-start拥塞避免congestion avoidance快重传fast retransmit快恢复fast recovery
为了简单起见我们假设发送方A接收方BA只发送数据报B只发送确认报。并且接收方的接收窗口足够大此时发送方的发送窗口就只受拥塞控制的影响。
发送方维护一个叫做拥塞窗口cwnd的状态变量其值取决于网络的拥塞程度并且动态变化。
拥塞窗口cwnd的维护原则只要网络没有出现拥塞拥塞窗口就再增大一些。网络出现拥塞拥塞窗口就减小一些。判断出现网络拥塞的依据没有按时收到应当到达的确认报文段即发生超时
发送方将拥塞窗口作为发送窗口swnd即swnd cwnd。
具体的拥塞控制可以参考 https://juejin.cn/post/6844903664566403085
实在是讲不出来
3.6 TCP可靠传输的实现
TCP基于以字节为单位的滑动窗口来实现可靠传输。
如图A与B建立了TCP连接
简单起见我们假设数据单方面发送并且没有拥塞影响即A发送数据报文段B只发送确认报文段并且发送窗口不会受到拥塞控制的影响
上方表格为待传输的数据的序号。
连接建立后B给A发送一个确认报文段rwnd20, ack23代表滑动窗口大小为20下一次给我传序号为23的数据。
发送方接收到这个确认报文段后构造出自己的发送窗口大小为20字节发送窗口从序号为23的数据开始它称为后沿直到序号为42的数据结束它称为前沿。
并且由于ack23发送方A可以将23号以前的数据从发送缓存中删除在接收到ack之前发送窗口中的数据都要留在发送缓存中。
发送窗口中的数据都是可以发送的数据发送窗口前沿右边的数据都是不允许发送的数据。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-S5SWkMJ5-1678504984188)(assets/image-20230310181508-0jd6o6q.png)]
后沿的移动情况有两种 不动、前移
前沿的移动情况有三种 不动、前移、后移。
接下来A向B发送10个字节的数据序号为23-33的数据被发送出去但是并不会从发送缓存中删除因为还没有收到确认ack。
假如接收方B收到了序号为25-27的数据由于23-24的数据还没接收到所以B发送的确认报文的确认号仍为23。这是接收方对23号数据发起的第一次重复确认因此不会触发超时重传机制。同时接收窗口为20没变。
当以后23-24号数据传到接收方接收方就会发送对于23-27号数据的确认报文如果rwnd的值仍为20接收方就会将接收窗口移动到28-47号数据。
发送方收到该确认报文后将23-27号数据从发送缓存中删除。同时发送窗口移动到28-47号数据。
当发送方发送的数据迟迟无法到达接收方重传计时器超时会重传发送窗口内已发送的数据并重新启动重传计时器。
注意 虽然发送方的发送窗口是根据接收方的接收窗口设置的但是在同一时刻发送方的发送窗口并不总是和接收方的接收窗口一样大。 因为网络具有一定的延时性。 对于不按序列号到达的数据应该如何处理TCP并无明确规定 如果丢弃虽然实现更简单了但是会浪费很多网络资源。通常存储在接收窗口中等到字节流中所缺少的字节收到后再按序号交付给上层的应用进程。 TCP要求接收方必须有累积确认和捎带确认机制这样可以减小传输开销。接收方可以在合适的时候发送确认也可以在自己有数据要发送时把确认信息捎带上。但是接收方不应该过分推迟发送确认消息否则会触发超时重传浪费资源。 TCP是全双工通信通信双方都在发送和接受报文段因此每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时一定要区分开。
3.7 TCP超时重传
刚才一直再说如果有一段报文迟迟没有发送会触发超时重传但并没有说如何选择重传的时机现在就来说说TCP对于超时重传的时机选择。
超时重传时间RTO的选择是计算机网络最复杂的问题之一。
假如发送方为A接收方为B。发送方A向接收方B发送数据报并记录时间A收到B的返回的确认报文段后再次记录时间。
这两个时间的差值为往返时间RTT。如果超时重传时间设置的比RTT小很多会触发不必要的重传。如果设置的比RTT大很多迟迟不超时重传太影响效率。所以我们要找到一个正好的时间这个时间比RTT大一点但大的不多。
听起来很简单但是复杂的网络环境使传输速率复杂多变RTT也跟着变化早上跟晚上的网络速率差别都很大。所以超时重传时间RTO的选择是计算机网络最复杂的问题之一。
这时候就不能以单次RTT的值确定RTO的值而是使用很多次RTT的值通过一定的算法来计算出一个更加合适的RTO。
我们使用RTT代表通过计算得出的RTT的值RTT(i)代表每一次TCP通信产生的RTT值
当第一次RTT产生时最终RTT的值等于第一次RTT的值。RTT RTT(1)
RTT多起来的时候使用公式 RTT (1-a)* 上一次RTT a*RTT(i) 在上式中0 ≤ a 1若a接近于0则RTT(i)对RTT的值的影响不大。若a接近于1则RTT(i)对RTT的影响较大。标准RFC298建议a的值为1/8
当通过每一次的样本计算得出最终RTT后我们就可以规定超时重传时间RTO略大于RTT了。 至此TCP就告一段落了。 4. UDP
由于UDP向应用层提供无连接不可靠的通信服务所以它无需像TCP那样实现流量控制、拥塞控制等等功能它的字段也十分简单。
一个UDP用户数据报同样由首部与数据载荷两部分组成首部格式如图所示。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ATMS6yO6-1678504984189)(assets/image-20230310190305-vf2p1ze.png)]
它只有四个字段每个字段两个字节共八个字节。由于UDP提供无连接不可靠的服务所以它只在网际层的基础上添加了端口号的区分。 至此UDP告一段落。。。才怪UDP的功能会在下小节UDP与TCP的区别中注明。因为实在太少。。。 5.TCP与UDP的区别
TCP与UDP所有的区别都是基于一个条件 TCP提供有连接可靠性传输服务UDP提供无连接不可靠服务。
如果TCP不提供可靠服务那他俩就一样了。 TCP传输数据前需要三报文握手建立连接传输数据结束时四报文挥手断开连接。 UDP可以随时发送数据。只要你知道它的IP就可以突然发送数据。 TCP只支持一对一的solo模式连接只能在两个主机之间进行。 UDP支持单播、多播、广播。 当应用层报文发送到传输层时 TCP将应用层传输的报文拆分为多个字节流标上序号再加上TCP首部封装为TCP数据报再根据发送策略发送给下层。TCP是面向字节流的。 UDP仅仅将应用层报文首部添加一个UDP首部封装为UDP数据报就将该数据报发送给接受方。UDP是面向数据报的。 如果数据传输过程中数据丢失、误码 TCP会重新发送或触发重传机制。 UDP啥也不干。
最后对比一下UDP数据报首部以及TCP数据报的首部格式
