那些网站是vue做的,做网站后端的是什么部门,学校网站网页模板,建设网站时的故障分类TCP/IP超全笔记 - TCP篇
什么是 TCP TCP#xff08;Transmission Control Protocol#xff0c;传输控制协议#xff09;是一种面向连接的、可靠的、基于字节流的传输层通信协议。 面向连接#xff1a;一对一#xff0c;先连接#xff0c;再传输数据可靠交付#xff1a;…TCP/IP超全笔记 - TCP篇
什么是 TCP TCPTransmission Control Protocol传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。 面向连接一对一先连接再传输数据可靠交付保证数据准确面向字节流把数据看成一连串的无结构字节流
网络模型
七层模型
应用层表示层会话层传输层TCP/UDP网络层: IP 寻址和路由选择路由器防火墙多层交换机 数据链路层 关注数据的传输和流控制、差错检测和纠正等逻辑控制功能数据单元是帧frame网卡、交换机MAC地址 物理层 主要是将数字信号转化为模拟信号并通过物理媒介传输信号关注传输媒介信号的传输和电气规范等物理特性数据单元是比特
五层模型
应用层传输层TCP/UDP网络层: IP数据链路层物理层
四层模型
应用层HTTP、FTP、SMTP传输层TCP/UDP数据包 Segment网络层: 负责数据的包装寻址和路由IP、RIP、ICMP数据包 Packet网络接口层ARP协议数据包 Frame
TCP 三次握手
client - server: SYN 1, seq u告诉服务器我准备连接了server - client: SYN 1, ACK 1, ack u 1, seq v告诉客户端我可以被连接client - server: ACK 1, ack v 1, seq u 1告诉服务器我准备开始传输数据 为啥要三次握手只要前两次握手不行么 因为网络是不可靠的如果只进行两次握手那么可能会出现如下情况 client发送第一个连接的请求报文但由于网络问题请求没有立即到服务端而是在网络节点滞留了直到某个时间才到达server但是这个时候可能已经变成了个失效的报文但是server还是以为client要连接它所以server会回复一个连接成功的报文但是client根本不会理睬所以server白白浪费了一个连接成功的报文。 为了避免这种情况所以要进行三次握手。 TCP 四次挥手
client - server: FIN 1, seq u告诉服务器我马上要关闭了server - client: ACK 1, ack u 1, seq v告诉客户端我知道你马上要关闭了 但服务端可能还有数据没发送完成所以这时候要等待server数据发送完成 server - client: FIN 1, seq wserver数据终于发送完了告诉客户端我马上也要关闭了client - server: ACK 1, ack w 1, seq u 1客户端收到server的FIN知道server要关闭了 client 处于TIME_WAIT状态等待2MSL后关闭连接为啥 client最后回的ACKserver可能会没收到从而导致server再次发送FIN如果client这时候已经关闭了那么就会导致server错误如果client发送最后的ACK之后直接进入关闭状态然后再次连接Server如果端口恰好相同的话且前一次的连接有数据滞留在网络中这个时候最新一次的连接就会收到上一次连接的脏数据导致数据包混乱。 TCP 状态流转
TCP 头部格式
源端口号16bit目标端口号16bit序列号32bit 一次TCP通信从连接建立到断开过程中某个传输方向上的字节流的字节在数据流上的索引 确认应答号32bit首部长度4bit tcp头有多少个32bit故TCP头最多60字节保留6bitURG1bitACK: 1bit用于确认应答PSH: 1bitRST: 1bitSYN: 1bit用于建立连接FIN: 1bit用于释放连接窗口大小16bit用于TCP流量控制接收缓冲区还能容纳多少字节的数据以便于发送方控制发送数据的速度校验和16bit用于数据校验紧急指针16bit选项可变长度数据
连接建立中的异常
SYN 攻击 攻击者伪造很多IP地址对目标服务器发送SYN连接请求服务器回复确认包并等待攻击者的ACK由于伪造IP地址所以攻击者根本不会回ACK导致服务器端一直处于等待状态从而导致服务器端资源耗尽无法为正常用户提供服务。 服务器没收到第三次握手ACK时会重发Linux环境下重发5次每次间隔1s、2s、4s、8s、16s、32s重发耗时很长短时间大量SYN请求会导致资源耗尽。 解决方案缩短重试时间间隔、 TCP如何实现可靠传输
停止等待方式
设定时间内未收到确认则进行重传发送数据完等待ACK效率低
流水线传输方式
采用滑动窗口协议允许发送端发送多个数据包而不需要等待对方确认当发送数据包达到窗口上限时停止发送窗口大小设置多少合适呢有没有说法接收端收到数据包后返回ACK发送端滑动窗口右移继续发送数据接收端发送的ACK并不一定是当前接收到的包序号而是返回已连续接收的最大的包序号1比如收到1,2,3这时候返回4表示我已经收到了4之前的报文如果后续收到了5,7,8回复的三个ACK都会是4然后又收到数据包4则ACK返回6发送端这时候就知道1-5都接收成功了滑动窗口直接右移到6开始超时重传机制发送端滑动窗口内数据包一定时间没收到ACK则会启动重发机制直到收到ACK。快速重传机制如果发送端收到同一报文的三次冗余确认就会认为这条报文的下一条丢失不管是否超时都会进行重发
TCP流量控制 接收端处理数据的能力有限如果发送太快超过了接收端处理能力就会把接收端缓冲区打满这时候就会导致丢包发送端又得重发。因此需要根据接收端能力来控制发送速度。 接收端发送ACK时返回窗口大小即剩余缓冲区大小。发送端根据接收端返回的窗口大小来控制发送速度。如果接收端返回窗口大小为0则发送端停止发送数据但仍需要定时发送一个窗口探测数据段不然发送端不知道啥时候接收端可以再接收数据了。
TCP拥塞控制 在不清楚当前网络状态下贸然发送大量数据可能会引起计算机网络的拥塞导致网络性能下降严重时甚至会导致网络瘫痪另外网络情况时刻在变化网络变得拥堵/空闲都要及时调整发送速度一方面避免加剧网络堵塞一方面最大限度地利用网络资源。因此TCP需要根据网络拥塞情况来动态调整发送数据量以避免网络拥塞。 慢启动
拥塞窗口先设置为1后面每次都翻倍直到出现数据传输超时或者触发了快速重传。如果传输超时可能网络出现严重堵塞需要立即减少发送这时候需要将慢启动阈值设置为拥塞窗口的一半然后重新开始慢启动过程拥塞窗口设置为1,直到拥塞窗口增加到慢启动阈值然后改为拥塞避免模式。如果触发了快速重传则将慢启动阈值减半然后将拥塞窗口设置为原先的一半 3触发快速重传说明发送端还能收到ACK说明网络没有那么严重的堵塞这时候减半发送就够了没必要降为1这时候进入快速恢复模式
拥塞避免 拥塞避免阶段是个速率增加缓慢且线性增长的过程 每收到一个ACK拥塞窗口1如果发生了超时则将慢启动阈值设置为拥塞窗口的一半然后重新开始慢启动过程拥塞窗口设置为1如果触发了快速重传则将慢启动阈值减半然后将拥塞窗口设置为原先的一半 3然后进入快速恢复模式
快速恢复
每收到一个冗余的确认报文则拥塞窗口1如果出现数据传输超时则将慢启动阈值设置为拥塞窗口的一半然后重新开始慢启动过程拥塞窗口设置为1如果发送方接收到新的确认报文则拥塞窗口设置为慢启动阈值然后进入拥塞避免模式 为啥收到冗余确认报文拥塞窗口还要1按理来说没有收到新的确认报文这个时候还是拥堵的为啥还有增长原因在于新收到冗余确认报文后意味着网络中腾出了一条报文的空间所以可以再发一条但是这个时候拥塞窗口已经满了只有再1才能再发一条数据。
