黄埔企业网站建设四川省住房与城乡建设厅网站管网

当前位置： 首页 > news >正文

黄埔企业网站建设,四川省住房与城乡建设厅网站管网,个人主页网站制作模板,wordpress版本号文章目录零. TCP和UDP的区别以及TCP详解TCP是如何保证可靠性的TCP超时重传的原理TCP最大连接数限制TCP流量控制和拥塞控制流量控制拥塞控制TCP粘包问题一、三次握手和四次挥手二、为什么要进行三次握手#xff1f;两次握手可以吗#xff1f;三、为什么要进行四次挥手#xf… 文章目录零. TCP和UDP的区别以及TCP详解TCP是如何保证可靠性的TCP超时重传的原理TCP最大连接数限制TCP流量控制和拥塞控制流量控制拥塞控制TCP粘包问题一、三次握手和四次挥手二、为什么要进行三次握手两次握手可以吗三、为什么要进行四次挥手三次可以吗四、第二次握手传回来了ACK为什么还要传回SYN五. CLOSE-WAIT和TIME-WAIT的状态和意义六. TIME-WAIT为什么是2MSL七. 有很多TIME-WAIT状态要如何解决八. 有很多CLOSE-WAIT状态要如何解决零. TCP和UDP的区别以及TCP详解 TCP是如何保证可靠性的 数据分块应用数据被分割成 TCP 认为最适合发送的数据块。序列号和确认应答TCP 给发送的每一个包进行编号在传输的过程中每次接收方收到数据后都会对传输方进行确认应答即发送 ACK 报文这个 ACK 报文当中带有对应的确认序列号告诉发送方成功接收了哪些数据以及下一次的数据从哪里开始发。除此之外接收方可以根据序列号对数据包进行排序把有序数据传送给应用层并丢弃重复的数据。校验和 TCP 将保持它首部和数据部分的检验和。这是一个端到端的检验和目的是检测数据在传输过程中的任何变化。如果收到报文段的检验和有差错TCP 将丢弃这个报文段并且不确认收到此报文段。流量控制TCP 连接的双方都有一个固定大小的缓冲空间发送方发送的数据量不能超过接收端缓冲区的大小。当接收方来不及处理发送方的数据会提示发送方降低发送的速率防止产生丢包。TCP 通过滑动窗口协议来支持流量控制机制。拥塞控制当网络某个节点发生拥塞时减少数据的发送。ARQ协议也是为了实现可靠传输的它的基本原理就是每发完一个分组就停止发送等待对方确认。在收到确认后再发下一个分组。超时重传当 TCP 发出一个报文段后它启动一个定时器等待目的端确认收到这个报文段。如果超过某个时间还没有收到确认将重发这个报文段。 TCP超时重传的原理 发送方在发送一次数据后就开启一个定时器在一定时间内如果没有得到发送数据报的ACK报文那么就重新发送数据在达到一定次数还没有成功的话就放弃重传并发送一个复位信号。其中超时时间的计算是超时的核心而定时时间的确定往往需要进行适当的权衡因为当定时时间过长会造成网络利用率不高定时时间过短会造成多次重传使得网络阻塞。在TCP连接的过程中会参考当前的网络状况从而找到一个合适的超时时间。 TCP最大连接数限制 Client 最大 TCP 连接数 client 在每次发起 TCP 连接请求时如果自己并不指定端口的话系统会随机选择一个本地端口local port该端口是独占的不能和其他 TCP 连接共享。TCP 端口的数据类型是 unsigned short因此本地端口个数最大只有 65536除了端口 0不能使用外其他端口在空闲时都可以正常使用这样可用端口最多有 65535 个。 Server最大 TCP 连接数 server 通常固定在某个本地端口上监听等待 client 的连接请求。不考虑地址重用Unix 的 SO_REUSEADDR 选项的情况下即使 server 端有多个 IP本地监听端口也是独占的因此 server 端 TCP 连接 4 元组中只有客户端的 IP 地址和端口号是可变的因此最大 TCP 连接为客户端 IP 数 × 客户端 port 数对 IPV4在不考虑 IP 地址分类的情况下最大 TCP 连接数约为 2 的 32 次方IP 数× 2 的 16 次方port 数也就是 server 端单机最大 TCP 连接数约为 2 的 48 次方。
TCP流量控制和拥塞控制 流量控制 流量控制就是让发送方的发送速率不要太快让接收方来得及接收。如果接收方来不及接收发送方发送的数据那么就会有分组丢失。在TCP中利用可变长的滑动窗口机制可以很方便低在TCP连接上实现对发送方的流量控制。 实现方式是接收端返回的ACK中会包含自己的接收端的滑动窗口大小以控制发送方此次发送的数据量大小。 如果接收方的滑动窗口满了基于TCP流量控制的滑动窗口协议接收方返回给发送方的接收窗口大小为 0此时发送方会等待接收方发送的窗口大小直到变为非 0 为止然而接收方回应的 ACK 包是存在丢失的可能的为了防止双方一直等待而出现死锁情况此时就需要坚持计时器来辅助发送方周期性地向接收方查询以便发现窗口是否变大。 拥塞控制 拥塞控制是作用于网络的它是防止过多的数据注入到网络中避免出现网络负载过大的情况。常用的解决方法有慢开始和拥塞避免、快重传和快恢复。 慢开始 当发送方开始发送数据时由于一开始不知道网络负荷情况如果立即将大量的数据字节传输到网络中那么就有可能引起网络拥塞。一个较好的方法是在一开始发送少量的数据先探测一下网络状况即由小到大的增大发送窗口拥塞窗口 cwnd。慢开始的慢指的是初始时令 cwnd为 1即一开始发送一个报文段。如果收到确认则 cwnd 2之后每收到一个确认报文就令 cwnd cwnd* 2。 但是为了防止拥塞窗口增长过大而引起网络拥塞另外设置了一个慢开始门限 ssthresh。 ① 当 cwnd ssthresh 时使用上述的慢开始算法 ② 当 cwnd ssthresh 时停止使用慢开始转而使用拥塞避免算法 ③ 当 cwnd ssthresh 时两者均可。 拥塞避免 拥塞控制是为了让拥塞窗口 cwnd 缓慢地增大即每经过一个往返时间 RTT 往返时间定义为发送方发送数据到收到确认报文所经历的时间就把发送方的 cwnd 值加 1通过让 cwnd 线性增长防止很快就遇到网络拥塞状态。 当网络拥塞发生时让新的慢开始门限值变为发生拥塞时候的值的一半,并将拥塞窗口置为 1 ,然后再次重复两种算法慢开始和拥塞避免,这时一瞬间会将网络中的数据量大量降低。 快重传 快重传算法要求接收方每收到一个失序的报文就立即发送重复确认而不要等到自己发送数据时才捎带进行确认假定发送方发送了 Msg 1 ~ Msg 4 这 4 个报文已知接收方收到了 Msg 1Msg 3 和 Msg 4 报文此时因为接收到收到了失序的数据包按照快重传的约定接收方应立即向发送方发送 Msg 1 的重复确认。 于是在接收方收到 Msg 4 报文的时候向发送方发送的仍然是 Msg 1 的重复确认。这样发送方就收到了 3 次 Msg 1 的重复确认于是立即重传对方未收到的 Msg 报文。由于发送方尽早重传未被确认的报文段因此快重传算法可以提高网络的吞吐量。 快恢复 快恢复算法是和快重传算法配合使用的该算法主要有以下两个要点
① 当发送方连续收到三个重复确认执行乘法减小慢开始门限 ssthresh 值减半 ② 由于发送方可能认为网络现在没有拥塞因此与慢开始不同把 cwnd 值设置为 ssthresh 减半之后的值然后执行拥塞避免算法线性增大 cwnd。 TCP粘包问题 为什么会出现TCP粘包和拆包 当发送方写入的数据大于socket的缓冲区的大小的时候需要拆包。或者当TCP报文的数据部门大小大于MSS最大报文长度的时候将会出现拆包。当发送方发送的数据太快接收方处理数据的速度赶不上发送端的速度的时候将会发生粘包。 解决方案 在消息的头部添加消息长度字段服务端获取消息头的时候解析消息长度然后向后读取相应长度的内容。设置消息边界也可以理解为分隔符服务端从数据流中按消息边界分离出消息内容一般使用换行符。 一、三次握手和四次挥手 二、为什么要进行三次握手两次握手可以吗 第一次握手客户端只是发送处请求报文段什么都无法确认而服务器可以确认自己的接收能力和对方的发送能力正常 第二次握手客户端可以确认自己发送能力和接收能力正常对方发送能力和接收能力正常 第三次握手服务器可以确认自己发送能力和接收能力正常对方发送能力和接收能力正常 可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常这样就可以愉快地进行通信了。 一方面如果只有第二次握手,服务端发给客服端的包丢了之后,服务端就直接建立了连接,然后一直傻等,从而造成服务器系统调用超时返回。 另一个方面TCP 实现了可靠的数据传输原因之一就是 TCP 报文段中维护了序号字段和确认序号字段通过这两个字段双方都可以知道在自己发出的数据中哪些是已经被对方确认接收的。这两个字段的值会在初始序号值得基础递增如果是两次握手只有发送方比如客户端的初始序号可以得到确认而另一方的初始序号则得不到确认。 三、为什么要进行四次挥手三次可以吗 四次挥手可以被抽象为如下过程 Client 请求关闭Server: 同意该请求Server: 请求关闭Client: 同意该请求 考虑以下服务器遭遇的场景 先同意对方关闭连接对方无法传输数据第二次挥手 自己若还有数据未发送完接着发送直至全部发送完毕 请求自身关闭连接第三次挥手 客户端同意第四次挥手 如果说服务器在客户端请求关闭连接的一瞬间已经没有任何数据需要发送了那么三次挥手应该也是可以的但是在实际生产环境中这样的情况几乎没有所以需要服务器先把自己的所有数据发送完毕因此四次挥手更加稳妥。 或者也可以这么回答 释放 TCP 连接时之所以需要四次挥手是因为 FIN 释放连接报文和 ACK 确认接收报文是分别在两次握手中传输的。 当主动方在数据传送结束后发出连接释放的通知由于被动方可能还有必要的数据要处理所以会先返回 ACK 确认收到报文。当被动方也没有数据再发送的时候则发出连接释放通知对方确认后才完全关闭TCP连接。 四、第二次握手传回来了ACK为什么还要传回SYN ACK是为了告诉客户端发来的数据接收无误传回SYN是为了把自己的初始序列号同步到客户端。 五. CLOSE-WAIT和TIME-WAIT的状态和意义 CLOSE- WAIT发生在第二次挥手请求发送之后。 在服务器收到了客户端关闭连接的请求并且告诉客户端自己已经成功收到了该请求之后服务器进入了CLOSE- WAIT状态然而此时有可能服务端还有一些数据还没有传输完成CLOSE- WAIT状态就是用来保证服务器在关闭连接之前能够将待发送的所有数据发送完成因此不能立即关闭连接。 TIME-WAIT发生在第四次挥手的时候当客户端向服务端发送ACK确认报文后进入该状态。作用有两个 客户端立即关闭后,立即又用同样的端口握手并建立通信,此时上次的连接残留的数据包会被误认为是最新连接的,造成数据异常客户端直接关闭后,若服务端重新发送 fin 包,客户端就会回应 RST,会报异常,但是其实是没有问题的 六. TIME-WAIT为什么是2MSL 当客户端发出最后的ACK确认报文时并不能确定服务器能够接收到该段报文。所以客户端在发送完ACK确认报文之后会设置一个时长为2MSL的计时器。 如果服务器在1MSL后仍然没有收到客户端发送的ACK确认报文那么它会向客户端重传FIN报文对客户端而言从客户端发出ACK报文起重传的FIN报文的最晚到达时间是2MSL。 若服务器在1MSL内没有收到客户端发出的ACK确认报文再次向客户端发送FIN释放连接报文。若客户端在2MSL内收到了服务器在此发来的FIN报文客户端将再次向服务器发出ACK确认报文并重新开始2MSL的计时。 七. 有很多TIME-WAIT状态要如何解决 服务器可以设置 SO_REUSEADDR 套接字选项来通知内核如果端口被占用但 TCP 连接位于 TIME_WAIT 状态时可以重用端口。如果你的服务器程序停止后想立即重启而新的套接字依旧希望使用同一端口此时 SO_REUSEADDR 选项就可以避免 TIME-WAIT 状态。 实际上要建立长连接的话就需要使用SO_REUSEADDR关键字。 八. 有很多CLOSE-WAIT状态要如何解决 一般来说系统内不会出现很多CLOSE- WAIT第二次挥手后服务器出现的状态。我们可以首先检查一下是不是自己的代码出现了问题比如查看服务端是否忘记关闭连接。其次我们可以调整系统参数包括句柄相关参数和TCP/IP的参数一般一个CLOSE_WAIT会维持至少两个小时。