广东网站开发软件,现在做推广有什么好的方法,创新的医疗网站建设,平面设计软件图标1 UDP
1.1 ⾯向报⽂
UDP 是⼀个⾯向报⽂#xff08;报⽂可以理解为⼀段段的数据#xff09;的协议。意思就是UDP 只是报⽂的搬运⼯#xff0c;不会对报⽂进⾏任何拆分和拼接操作
具体来说
在发送端#xff0c;应⽤层将数据传递给传输层的 UDP 协议#xff0c; UDP 只会…1 UDP
1.1 ⾯向报⽂
UDP 是⼀个⾯向报⽂报⽂可以理解为⼀段段的数据的协议。意思就是UDP 只是报⽂的搬运⼯不会对报⽂进⾏任何拆分和拼接操作
具体来说
在发送端应⽤层将数据传递给传输层的 UDP 协议 UDP 只会给数据增加⼀个 UDP头标识下是 UDP 协议然后就传递给⽹络层了在接收端⽹络层将数据传递给传输层 UDP 只去除 IP 报⽂头就传递给应⽤层不会任何拼接操作
1.2 不可靠性
UDP 是⽆连接的也就是说通信不需要建⽴和断开连接。UDP 也是不可靠的。协议收到什么数据就传递什么数据并且也不会备份数据对⽅能不能收到是不关⼼的UDP 没有拥塞控制⼀直会以恒定的速度发送数据。即使⽹络条件不好也不会对发送速率进⾏调整。这样实现的弊端就是在⽹络条件不好的情况下可能会导致丢包但是优点也很明显在某些实时性要求⾼的场景⽐如电话会议就需要使⽤ UDP ⽽不是 TCP
1.3 ⾼效
因为 UDP 没有 TCP 那么复杂需要保证数据不丢失且有序到达。所以 UDP 的头部开销⼩只有⼋字节相⽐ TCP 的⾄少⼆⼗字节要少得多在传输数据报⽂时是很⾼效的
头部包含了以下⼏个数据
两个⼗六位的端⼝号分别为源端⼝可选字段和⽬标端⼝ 整个数据报⽂的⻓度整个数据报⽂的检验和 IPv4 可选 字段该字段⽤于发现头部信息和数据中的错误
1.4 传输⽅式
UDP 不⽌⽀持⼀对⼀的传输⽅式同样⽀持⼀对多多对多多对⼀的⽅式也就是说 UDP 提供了单播多播⼴播的功能
2 TCP
2.1 头部
TCP 头部⽐ UDP 头部复杂的多对于 TCP 头部来说以下⼏个字段是很重要的Sequence number 这个序号保证了 TCP 传输的报⽂都是有序的对端可以通过序号顺序的拼接报⽂Acknowledgement Number 这个序号表示数据接收端期望接收的下⼀个字节的编号是多少同时也表示上⼀个序号的数据已经收到Window Size 窗⼝⼤⼩表示还能接收多少字节的数据⽤于流量控制
标识符
URG1 该字段为⼀表示本数据报的数据部分包含紧急信息是⼀个⾼优先级数据报⽂此时紧急指针有效。紧急数据⼀定位于当前数据包数据部分的最前⾯紧急指针标明了紧急数据的尾部。ACK1 该字段为⼀表示确认号字段有效。此外 TCP 还规定在连接建⽴后传送的所有报⽂段都必须把 ACK 置为⼀ PSH1 该字段为⼀表示接收端应该⽴即将数据 push 给应⽤层⽽不是等到缓冲区满后再提交。RST1 该字段为⼀表示当前 TCP 连接出现严重问题可能需要重新建⽴ TCP 连接也可以⽤于拒绝⾮法的报⽂段和拒绝连接请求。SYN1 当 SYN1 ACK0 时表示当前报⽂段是⼀个连接请求报⽂。当 SYN1 ACK1 时表示当前报⽂段是⼀个同意建⽴连接的应答报⽂。FIN1 该字段为⼀表示此报⽂段是⼀个释放连接的请求报⽂
2.2 状态机
HTTP 是⽆连接的所以作为下层的 TCP 协议也是⽆连接的虽然看似TCP 将两端连接了起来但是其实只是两端共同维护了⼀个状态TCP 的状态机是很复杂的并且与建⽴断开连接时的握⼿息息相关接下来就来详细描述下两种握⼿。在这之前需要了解⼀个重要的性能指标 RTT。该指标表示发送端发送数据到接收到对端数 据所需的往返时间
建⽴连接三次握⼿
在 TCP 协议中主动发起请求的⼀端为客户端被动连接的⼀端称为服务端。不管是客户端还是服务端 TCP 连接建⽴完后都能发送和接收数据所以 TCP 也是⼀个全双⼯的协议。起初两端都为 CLOSED 状态。在通信开始前双⽅都会创建 TCB 。 服务器创建完TCB 后遍进⼊ LISTEN 状态此时开始等待客户端发送数据 第⼀次握⼿ 客户端向服务端发送连接请求报⽂段。该报⽂段中包含⾃身的数据通讯初始序 号。请求发送后客户端便进⼊ SYN-SENT 状态x 表示客户端的数据通信初 始序号。
第⼆次握⼿
服务端收到连接请求报⽂段后如果同意连接则会发送⼀个应答该应答中也会包含⾃身的数据通讯初始序号发送完成后便进⼊ SYN-RECEIVED 状态。
第三次握⼿
当客户端收到连接同意的应答后还要向服务端发送⼀个确认报⽂。客户端发完这个报⽂段后便进⼊ ESTABLISHED 状态服务端收到这个应答后也进⼊ESTABLISHED 状态此时连接建⽴成功。
PS第三次握⼿可以包含数据通过 TCP 快速打开 TFO 技术。其实只要涉及到握⼿的协议都可以使⽤类似 TFO 的⽅式客户端和服务端存储相同 cookie 下次握⼿时发出 cookie 达到减少 RTT 的⽬的
你是否有疑惑明明两次握⼿就可以建⽴起连接为什么还需要第三次应答
因为这是为了防⽌失效的连接请求报⽂段被服务端接收从⽽产⽣错误可以想象如下场景。客户端发送了⼀个连接请求 A但是因为⽹络原因造成了超时这时 TCP 会启动超时重传的机制再次发送⼀个连接请求 B。此时请求顺利到达服务端服务端应答完就建⽴了请求。如果连接请求 A 在两端关闭后终于抵达了服务端那么这时服务端会认为客户端⼜需要建⽴ TCP 连接从⽽应答了该请求并进⼊ ESTABLISHED 状态。此时客户端其实是 CLOSED 状态那么就会导致服务端⼀直等待造成资源的浪费PS在建⽴连接中任意⼀端掉线TCP 都会重发 SYN 包⼀般会重试五次在建⽴连接中可能会遇到 SYN FLOOD 攻击。遇到这种情况你可以选择调低重试次数或者⼲脆在不能处理的情况下拒绝请求
断开链接四次握⼿
TCP 是全双⼯的在断开连接时两端都需要发送 FIN 和 ACK 。
第⼀次握⼿
若客户端 A 认为数据发送完成则它需要向服务端 B 发送连接释放请求。
第⼆次握⼿
B 收到连接释放请求后会告诉应⽤层要释放 TCP 链接。然后会发送 ACK包并进⼊ CLOSE_WAIT 状态表示 A 到 B 的连接已经释放不接收 A 发的数据了。但是因为 TCP 连接时双向的所以 B 仍旧可以发送数据给 A。
第三次握⼿
B 如果此时还有没发完的数据会继续发送完毕后会向 A 发送连接释放请求然后 B 便进⼊ LAST-ACK 状态。PS通过延迟确认的技术通常有时间限制否则对⽅会误认为需要重传可以将第⼆次和第三次握⼿合并延迟 ACK 包的发送。
第四次握⼿
A 收到释放请求后向 B 发送确认应答此时 A 进⼊ TIME-WAIT 状态。该状态会持续2MSL最⼤段⽣存期指报⽂段在⽹络中⽣存的时间超时会被抛弃 时间若该时间段内没有 B 的重发请求的话就进⼊ CLOSED 状态。当 B 收到确认应答后也便进⼊CLOSED 状态。
为什么 A 要进⼊ TIME-WAIT 状态等待 2MSL 时间后才进⼊ CLOSED 状态
为了保证 B 能收到 A 的确认应答。若 A 发完确认应答后直接进⼊ CLOSED 状态如果确认应答因为⽹络问题⼀直没有到达那么会造成 B 不能正常关闭
