做封面怎么把网站加上去,泰安的网站建设公司,联联周边游官网app下载,wordpress怎么弄登录计网tcp部分面试总结
tcp报文格式#xff1a;
序列号#xff1a;通过SYN传给接收端#xff0c;当SYN为1#xff0c;表示请求建立连接#xff0c;且设置序列号初值#xff0c;后面没法送一次数据#xff0c;就累加数据大小#xff0c;保证包有序。 确认应答号#x…计网tcp部分面试总结
tcp报文格式
序列号通过SYN传给接收端当SYN为1表示请求建立连接且设置序列号初值后面没法送一次数据就累加数据大小保证包有序。 确认应答号下次希望收到的数据序列号发送端收到后可认为这个序列号之前的数据都接受了保证不丢包。 控制位ACK为1时确认应答字段生效;RST为1时表示连接异常必须强制断开SYN前面说了FIN为1时表示请求断开连接。 校验和检查数据在传输过程中是否有改动。 TCP:面向连接(一对一)、可靠(保证报文有序完整到达接收端)、基于字节流(下面会解释)的协议。 如何唯一确定一个 TCP 连接源ip,源端口目标ip,目标端口 UDP:区别TCP面向连接可靠基于字节流传输一对一有拥塞控制流量控制首部开销大UDP:无连接不可靠基于包传输(不拆分)支持一对一一对多多对多无拥塞控制流量控制首部开销小(只有源端口目标端口)应用TCP用于文件传输https;UDP用于直播
三次握手
开始都是关闭状态。服务器先监听某个端口处于listen。 1.客户端发送第一个SYN报文请求建立连接其中SYN1,随机初始化序列号处于SYN_SENT。 2.服务端收到SYN报文回一个SYN报文SYN1(我也请求连接),ACK1(表示确认收到)确认应答号客户端的序列号1(表示我希望下一次收到这个序号)也随机初始化序列号处于SYN_RCVD。 3.客户端收到SYN报文回一个应答报文ACK1(表示我收到了你的报文)确认应答号服务端序列号1这次报文可以带数据客户端处于ESTABLISHED服务端收到应答报文也进入ESTABLISHED。连接建立完成。 为什么是3次握手不是2次4次 1、3次握手可以确认双方的收发能力同步双方的初始序列号。2次握手服务端不能确定客户端是否收到自己的报文。 2、避免在旧连接中发送数据举例客户端先发SYN报文seq90,然后断开了客户端重连又发送SYN报文seq100要建立新连接现在旧报文(seq90)先到了,服务端回一个SYNack报文确认号91客户端收到后发现确认号不是101(这个他能算出来)就会发送RST报文服务端收到后释放连接,整个过程是没有发送数据的。那要是服务端在收到RST报文前收到了新SYN就会回一个challenge ACK报文(收到乱序的SYN时就会回一个)是上一次的确认号91那客户端收到还是会发RST报文。若是2次握手当服务端收到syn就进入ESTABLISHED第2次握手就可以发数据给客户端客户端收到后会rst即这段时间发送的数据全浪费了。 至于4次握手3次已经能建立可靠连接也就没必要4次。 第一次握手丢失客户端一直收不到服务端SYN-ACK报文会超时重传且每次超时时间翻倍达到最大重传次数或者最大超时时间断开连接。 第二次握手丢失客户端一直收不到SYN-ACK会超时重传SYN,服务端收不到第3次握手也会重传SYN-ACK,服务端收到重传的SYN也没用当双方达到最大重传次数或者最大超时时间断开连接。 第三次握手丢失服务端收不到ACK应答报文会超时重传第2次握手直到达到次数。 四次挥手
(假设)客户端发送FIN报文请求关闭连接处于FIN_WAIT_1服务端收到报文发送ACK应答报文进入CLOSE_WAIT状态客户端收到ACK后进入FIN_WAIT_2状态服务端处理完数据也向客户端发送FIN报文进入LAST_ACK客户端收到FIN报文回一个ACK进入TIME_WAIT服务端收到ACK关闭连接客户端在2MSL后关闭连接。 为什么要4次挥手客户端发送FIN表示我不发了但我还能收你赶紧把剩下数据发过来服务端收到先应答确认收到然后处理数据处理完毕发送FIN表示我也不发了客户端收到回个ACK确认收到结束。所以是4次。但若被动方没数据发送且开启了tcp延迟确认机制(当发送不带数据的ack时会等待一段时间若有数据就一起发送)就会23合并。 第一次挥手丢失客户端收不到ACK应答会超时重传达到次数就断开连接。 第二次挥手丢失服务端收到FIN回一个ACK进入close_wait,但ACK报文是不会重传的所以客户端会触发超时重传FIN达到次数就断开连接。 第三次挥手丢失服务端处理完数据发送FIN丢失若一直收不到应答就会重传达到次数断开且客户端处于FIN_WAIT_2等待FIN是有时间限制的达到时间也会断开连接 第四次挥手丢失客户端会ACK进入TIME_WAIT2MSL后关闭服务端收不到ACK应答会重传FIN,客户端处于2MSL时若收到FIN会重发ACK重置2MSL定时器。 为什么需要TIME_WAIT状态(为什么要等待一段时间)防止第4次握手丢失等待服务端FIN重传,若直接关闭重传的FIN可能被新的相同四元组连接接收到数据错乱所以要等待一段时间。那为啥等待2MSL: MSL报文最大生存时间1MSL第4次挥手ACK不管到没到肯定消失若到了不用重传没到肯定会在1MSL后重传重传过来最多1MSL。1MSL所以2MS能保证若重传了FIN我一定能收到。至于不继续等3MSL4MSL连续丢包的概率很小忽略它比等待性价比高。 TIME_WAIT过多危害客户端过多(主动发起关闭连接方)(会占用端口资源若占满了就不能和当前服务器的当前端口建立连接了但是端口是可以复用的所以可以和其他端口或其他服务器建立连接因为tcp是由四元组确定。服务端过多不会导致端口资源受限因为不同的客户端与服务端建立tcp连接使用的四元组肯定不同端口可以复用但tcp连接太多会占用系统资源如文件描述符内存等。 不要优化TIME_WAIT,服务端若想避免过多的TIME_WAIT就让客户端去断开让分布在各处的客户端承受TIME_WAIT。服务器主动请求断开连接进入TIME_WAIT的情况:http长连接超时、长连接请求达到数量也会主动关闭这个长连接。 挥手过程中若服务端的FIN比它发送的数据包先到FIN先到就是乱序的会加入到乱序队列不会进入TIMEWAIT等待数据到达检查顺序再处理FIN,进入TIMEWAIT 服务器出现大量close_wait的连接的原因服务器内部由大量数据处理都没处理完或者出bug了解决停止程序改bug。 tcp连接中一段断电与进程崩溃的区别客户端断电即主机宕机服务端无法感知到客户端宕机所以搞了个保活机制每隔一段时间发送一个探测报文(你还在吗)若连续几个探测报文都没响应就会认为当前tcp连接死亡若期间客户端重启了收到探测报文内核会发送RST。若是进程崩溃内核回回收进程资源并完成挥手操作。 websocket和socket:socketip端口协议他是一套标准实现对下层协议栈的高度封装屏蔽网络细节方便网络编程。Websocket是应用层协议,是全双工的解决http/1.1半双工的问题服务器可以主动推送消息。他与http/2很像都用2进制传输都是全双工但他只在提供实时双向通信如聊天室http/2旨在提高性如浏览器。 socket编程建立连接的过程双方初始化socket得到文件描述符(客户端是传输描述符服务端是监听描述符)服务端bind,socket绑定ip和端口调用listen监听调用accept等待连接成功接收socket客户端connect,向服务端ip和端口请求连接(这个函数完成3次握手)服务端accept返回通信的socket自此双方都有传输的socket即可通信。客户端断开调用shutdown/close,则服务端处理完数据后也会调用shutdown/close,连接关闭。 listen的baklog参数意义就是设置全连接(accept)队列长度。 服务端bind,但没有listen客户端connect:肯定连不上回RST。 没有accept还能建立连接吗可以。调用listen监听会为socket分配2个队列全连接半连接收到第一次握手socket放入半连接队列收到第3次握手把socket移到全连接队列accept()等待全连接队列有连接就取出使用。所以accept不参与建立连接过程。 既然 IP 层会MTU为什么 TCP 层还需要 MSS 呢若tcp层不分片全交给ip层分片当某一个ip分片丢失接收方的ip层无法组成一个完整的ip报文也就无法把数据给tcp层也就不会发ACK响应回去发送方的tcp触发超时重传重发整个tcp报文给ip层因为不分片则ip层所有的分片都要重发所以tcp要分片。 SYN攻击若短时间伪造大量不同ip的SYN发送给服务端服务端回复SYNACK不会收到应答慢慢的占满SYN队列后面的SYN就会被丢弃。解决方法防火墙过滤增大半连接队列减小SYNACK重传次数或超时时间加速断开连接开启syncookie当收到SYN时不放入半连接队列会发送一个带特殊序列号的SYNACK当收到ack后才建立连接。 SYN报文在哪些情况下会被抛弃1.半连接队列满了2.半连接队列没满全连接队列满了3.半连接全连接都没满但当前半连接队列长度max_syn_backlog的3/4,也会丢弃 如何增大全连接队列全连接长min(somaxconn(系统设定的全连接长度上限),backlog(listen函数的参数我们设定的长度)) 如何增大半连接队列半连接长max(max_syn_backlog系统设定的半连接队列上限, 全连接长)*2所以要增大3个参数 客户端断开上线发送SYN关键就在于源端口号是否与之前的相同若SYN端口号与历史连接不同那就建立新的连接旧连接有保活机制让他死亡。若端口号与历史连接相同服务端收到SYN后发现序列号不对会回一个challengACK再次确认(收到了乱序的SYN)客户端收到发现ack不对,回RST。 如何不杀死进程关闭TCP连接伪造一个RST报文先通过工具killcx发送四元组相同的SYN服务端会回一个challengeACK(收到了乱序的SYN),就拿到它的确认号了就用这个确认号做RST的序列号发给服务端。 处于TIME_WAIT的客户端收到SYN:这里就不会发challengack了看SYN的序列号和时间戳是否合法若序列号比客户端确认号大且时间戳也比客户端最后收到的报文时间戳大就合法。直接重用建立连接。不合法回一个第四次挥手的ACK服务端收到发现不对回RST。处于time_wait收到rst:有一个参数若是0就断开连接若是1就丢掉RST。 TCP如何保证可靠传输3次握手建立连接确认通信实体存在序列号、确认号保证数据有序完整到达校验和校验数据是否有改动重传机制(解决丢包问题)流量控制(控制发送方发送速度)、拥塞控制(根据网络拥堵情况控制发送速率) 重传机制1.超时重传当某一方收不到响应会超时重传超时时间RTO略大于RTT(往返时延)且每重传一次时间会翻倍所以他的问题就是超时周期可能较长(可能要一直发到最大重传次数或者达到最大超时时间)。2.快速重传不以时间驱动以数据驱动举例发送方发送seq1,服务端回ack2,发送端发seq2丢了然后他发seq345(没有超时重传)接收端回3个ack2(表示我希望接收2你给我发345干嘛)发送方继续发当连续收到3个相同的ack(2次可能是乱序3次可能是丢包4次更可能是丢包)触发快速重传重传seq2,接收方回ack6。但它的问题就是若seq2,seq3都丢了可收到的都是ack2,那到底重传1个还是全部重传。3.SACK在tcp头部加SACK,告诉发送方我收到了哪些数据配合快速重传就可以知道到底要重发哪些包。 流量控制发送方若无脑发占满接收方缓冲区接收方处理不过来只能丢包浪费资源所以要考虑接收方的接收能力来发送数据这就是流量控制通过滑动窗口实现。窗口就是一块缓冲区把数据放在里面等待处理。Tcp报文中有个window字段发送方告诉发送方我还有多少剩余空间发送方根据这个大小来发送(窗口大小会变)。 窗口关闭当收到窗口大小为0发送方就不发了当处理完后发送方发窗口非0的ACK若丢失就会死锁所以当一方收到0窗口通知会开始计时超时会发送窗口探测报文若收到ACK说窗口还是0就重启计时器。若不是0就可以正常发了。 拥塞控制根据网络拥堵情况控制发送窗口的大小防止网络被淹没导致丢包。所以发送窗口的值min(拥塞窗口cwnd流控窗口rwnd)。 如何判断网络是否出现拥堵发生重传。拥塞控制4个算法刚开始慢启动发送方每收到一个ACK拥塞窗口大小1呈指数上升当cwndssthresh(慢启动门限)使用拥塞避免算法每收到一个ACKcwnd增加1/cwnd呈线性上升发生超时重传启动拥塞发生算法ssthresh变为cwnd/2,cwnd置为初始值又回到慢启动但这样像坐过山车太激进。 当发生快速重传ssthresh cwnd/2,然后使用快速恢复算法cwnd3,重传数据包若再收到重复的ACK,cwnd1(目的是你赶紧把丢的包发给我我给你留了空间),收到新的ACK表示丢的包已经重传恢复过程就结束了cwnd的值置为ssthresh又进入拥塞避免;可以看到只要发生重传即阻塞cwnd,ssthresh都会减小来应对网络拥堵,只是2种算法减小的程度不同。
如何区分流量控制和拥塞控制流量控制是根据接收方的窗口大小控制发送方的速度一方占满接收窗口丢包浪费资源拥塞控制是根据网络拥堵情况控制发送方的速度防止网络被淹没导致丢包。 TCP抓包工作再看 close与shutdown:调用close会把文件描述符的减一当减为0关闭通信socket所以他不影响其他进程shutdown是根据参数选择切断所有读/写/读写影响所有进程。shuwdown(fd, 0(关闭读),1(关闭写),2(关闭读写)); TCP优化三个角度优化三次握手、四次挥手、数据传输 三次握手优化客户端优化适当减少SYN报文和SYNACK报文的最大重传次数和最大超时时间增大半连接队列和全连接队列以应对多个连接。四次挥手优化主动方减少FIN超时重传次数;当收到ACK进入FIN_WAIT_2状态若是close函数关闭的连接关闭读写收到FIN会回RST,直接关闭就是3次挥手了(当被动方没有数据要发送且开启TCP延迟确认机制(默认开启即若没数据发送ACK会等一下看有没有数据一起走)23次回合并close/shutown都是3次挥手)是孤儿连接(不能读写但占资源)可设置孤儿连接的数量参数超过孤儿连接的数量直接关闭若是shutdown关闭的连接可以指定关闭写不关闭读就是正常的四次挥手可以设置FIN_WAIT_2的时间。被动方FIN重传次数若是close设置孤儿连接的数量传输数据优化调整接收方窗口大小关键就是调整内核缓冲区大小调整至与网络传输能力匹配即缓冲区上限设为带宽时延积。 TCP是面向字节流的协议UDP传输是不分片的直接加个头部给网络层一个消息对应一个报文所以他是面向报文的协议而TCP数据可能会被分成一个个报文段发出去具体是这样的在TCP里数据没有边界即发送方把数据视为一连串的字节流分片时不用管在哪切割像流一样有序发送到了再组装所以他是面向字节流的协议。但是会出现粘包问题如2个消息hi,hello,可能是这样hihello,h,ihello…因为没有边界。所以一般设置特殊字符做边界如http设置回车、换行做边界还可以定义消息结构如包头包体包头固定大小且含有包体大小。 为什么 TCP 每次建立连接时要随机初始化序列号主要是防止历史报文被新的相同四元组的来连接接收如一个连接断了但是还有历史报文此时又建立了一个相同四元组的连接他能接收到历史报文若他的序列号与之前相同那被完美接收了数据错乱。所以要随机初始化序列号保证每次连接序列号不同。使用随机算法但不能完全避免(有上限会回绕),所以要配合时间戳,若数据包时间戳不是递增的说明他是过期的。2者配合就能解决历史报文被接收的问题。序列号怎么变化的目前是m,发送n的数据(若是SYN/FIN,n取1)则变为mn确认号目前是m,表示我想收到序列号为m的数据收到后变为m数据长 http和tcp的保活是一个东西吗http的keep-alive也叫长连接该功能是应用程序实现的使得一个tcp处理多个请求应答它的超时时间由keepalivetimeout参数设置。tcp的keepalive是保活机制是内核实现的(tcp都在内核里)内核发送探测报文确认对方是否在线。 TCP 协议有什么缺陷建立连接的耗时(三次握手tls四次握手)、接收窗口队头阻塞、网络迁移要重新建立TCP(ip变了)更新很难(tcp在内核实现)。 UCP实现可靠传输通过QUIC实现目前的http/3就使用了基于UDP的QUIC协议。QUIC把http/2TCPUDP,tls1.3结合了。 建立连接基于tls1.3UDP一个rtt就协商出连接ID和通信密钥建立连接比tcp更快。 拥塞控制QUIC把TCP的拥塞控制算法在应用层实现热插拔方便更新。 解决队头阻塞首先他支持并发传输(http/2)QUIC为每个流开一个窗口多个流之间互不依赖解决多个流的队头阻塞但是单个流中若丢包还是会阻塞。 可靠传输(完整有序)也有包号和应答号以及重传机制但包号是递增的即使你重传也不是原来的所以在数据包中添加offset偏移量接收端根据偏移量排序以此来保证可可奥传输。这样设计的好处是计算RTT更精确TCP计算有歧义对于原始报文和重传报文返回的是相同的ACK那RTT按谁算呢QUIC通过包号直接能判断谁是原始的ACK谁是重传的ACK。 但是QUIC比TCP更加占用系统资源所以2者各有长处。 TCP和UDP可以同时绑定相同的端口吗可以TCP和UDP在内核里是2个独立模块主机收到数据包查看字段判断出是TCP/UDP,然后发给对应的模块处理TCP/UDP处理好了在发给进程。多个TCP能绑定相同的端口吗不行四元组确定唯一的TCP除非使用SO_REUSEPORT 端口复用。 用了TCP数据一定不会丢吗:数据会丢不可避免但丢包tcp可以重传实现传输层到传输层的可靠传输。但不保证数据到应用层是否可靠所以还需要第三方服务器来对账。 TCP 有哪些机制用于提高传输效率滑动窗口实现一次性发送多条数据而不用等待回复解决了接收方队头阻塞问题快速重传之前的超时重传必须达到最大重传次数或最大超时时间才会重传快充穿实现发送端收到3个相同就会立刻重传延迟确认当发送不带数据的ACK,会等待一段时间若有数据一起发送过去。
