wordpress建站多个域名,wordpress调用ja,p2p系统网站开发,淘宝网官方网站网页版TCP
#xff08;1#xff09;TCP 的 accept 发生在三次握手的哪个阶段#xff1f;
如下图connect和accept的关系#xff1a; accept过程发生在三次握手之后#xff0c;三次握手完成后#xff0c;客户端和服务器就建立了tcp连接并可以进行数据交互了。这时可以调用accep…TCP
1TCP 的 accept 发生在三次握手的哪个阶段
如下图connect和accept的关系 accept过程发生在三次握手之后三次握手完成后客户端和服务器就建立了tcp连接并可以进行数据交互了。这时可以调用accept函数获得此连接。
2connect返回了可以认为连接成功了吗
connect返回成功后三次握手就已经完成了。已完成的链接会被放入一个队列中accept的作用就是从已连接队列中取出优先级最高的一个链接并将它绑定给一个新的 fd服务端就可以通过这个新的 fd 来 recv 和 send 数据了。
3三次握手过程中可以携带数据么
第三次握手的时候可以携带。前两次握手不能携带数据。如果前两次握手能够携带数据那么一旦有人想攻击服务器那么他只需要在第一次握手中的 SYN 报文中放大量数据那么服务器势必会消耗更多的时间和内存空间去处理这些数据增大了服务器被攻击的风险。第三次握手的时候客户端已经处于ESTABLISHED状态并且已经能够确认服务器的接收、发送能力正常这个时候相对安全了可以携带数据。
4等待2MSL的意义如果不等待会怎样
如果不等待客户端直接跑路当服务端还有很多数据包要给客户端发且还在路上的时候若客户端的端口此时刚好被新的应用占用那么就接收到了无用数据包造成数据包混乱。所以最保险的做法是等服务器发来的数据包都死翘翘再启动新的应用。那照这样说一个 MSL 不就不够了吗为什么要等待 2 MSL?
1 个 MSL 确保四次挥手中主动关闭方最后的 ACK 报文最终能达到对端1 个 MSL 确保对端没有收到 ACK 重传的 FIN 报文可以到达
这就是等待 2MSL 的意义。
SYN Flood 攻击
1SYN Flood 攻击原理SYN Flood 属于典型的 DoS/DDoS 攻击。其攻击的原理很简单就是用客户端在短时间内伪造大量不存在的 IP 地址并向服务端疯狂发送SYN。对于服务端而言会产生两个危险的后果:
处理大量的SYN包并返回对应ACK, 势必有大量连接处于SYN_RCVD状态从而占满整个半连接队列无法处理正常的请求。由于是不存在的 IP服务端长时间收不到客户端的ACK会导致服务端不断重发数据直到耗尽服务端的资源。
2如何应对 SYN Flood 攻击
增加 SYN 连接也就是增加半连接队列的容量。减少 SYN ACK 重试次数避免大量的超时重发。利用 SYN Cookie 技术在服务端接收到SYN后不立即分配连接资源而是根据这个SYN计算出一个Cookie连同第二次握手回复给客户端在客户端回复ACK的时候带上这个Cookie值服务端验证 Cookie 合法之后才分配连接资源。
3TCP Fast Open 注意: 客户端最后握手的 ACK 不一定要等到服务端的 HTTP 响应到达才发送两个过程没有任何关系。第一次握手时server会计算出cookie传给客户端并缓存之后的握手客户端会携带cookie进行SYN。如果cookie不合法直接丢弃如果合法就可以直接发送http响应。4TFO 的优势TFO 的优势并不在与首轮三次握手而在于后面的握手在拿到客户端的 Cookie 并验证通过以后可以直接返回 HTTP 响应充分利用了1 个RTT(Round-Trip Time往返时延)的时间提前进行数据传输积累起来还是一个比较大的优势。
5序列号回绕怎么办
现在我们来模拟一下这个问题。序列号的范围其实是在0 ~ 2 ^ 32 - 1, 为了方便演示我们缩小一下这个区间假设范围是 0 ~ 4那么到达 4 的时候会回到 0。 假设在第 6 次的时候之前还滞留在网路中的包回来了那么就有两个序列号为1 ~ 2的数据包了怎么区分谁是谁呢这个时候就产生了序列号回绕的问题。那么用 timestamp 就能很好地解决这个问题因为每次发包的时候都是将发包机器当时的内核时间记录在报文中那么两次发包序列号即使相同时间戳也不可能相同这样就能够区分开两个数据包了。附timestamp是 TCP 报文首部的一个可选项一共占 10 个字节格式如下:
kind(1 字节) length(1 字节) info(8 个字节)
其中 kind 8 length 10 info 有两部分构成: timestamp和timestamp echo各占 4 个字节。 资料直通车Linux内核源码技术学习路线视频教程内核源码 学习直通车Linux内核源码内存调优文件系统进程管理设备驱动/网络协议栈 能不能说说 Nagle 算法和延迟确认
1Nagle 算法试想一个场景发送端不停地给接收端发很小的包一次只发 1 个字节那么发 1 千个字节需要发 1000 次。这种频繁的发送是存在问题的不光是传输的时延消耗发送和确认本身也是需要耗时的频繁的发送接收带来了巨大的时延。而避免小包的频繁发送这就是 Nagle 算法要做的事情。具体来说Nagle 算法的规则如下
当第一次发送数据时不用等待就算是 1byte 的小包也立即发送。后面发送满足下面条件之一就可以发了:数据包大小达到最大段大小(Max Segment Size, 即 MSS)之前所有包的 ACK 都已接收到
2延迟确认试想这样一个场景当我收到了发送端的一个包然后在极短的时间内又接收到了第二个包那我是一个个地回复还是稍微等一下把两个包的 ACK 合并后一起回复呢延迟确认(delayed ack)所做的事情就是后者稍稍延迟然后合并 ACK最后才回复给发送端。TCP 要求这个延迟的时延必须小于500ms一般操作系统实现都不会超过200ms。不过需要主要的是有一些场景是不能延迟确认的收到了就要马上回复:
接收到了大于一个 frame 的报文且需要调整窗口大小TCP 处于 quickack 模式通过tcp_in_quickack_mode设置发现了乱序包
两者一起使用会怎样前者意味着延迟发后者意味着延迟接收会造成更大的延迟产生性能问题。
TCP的Keep Alive和HTTP的Keep Alive的区别
TCP keepalive
在双方长时间未通讯时如何得知对方还活着如何得知这个TCP连接是健康且具有通讯能力的TCP的保活机制就是用来解决此类问题的保活机制默认是关闭的TCP连接的任何一方都可打开此功能。若对端正常存活且连接有效对端必然能收到探测报文并进行响应。此时发送端收到响应报文则证明TCP连接正常重置保活时间计数器即可。若由于网络原因或其他原因导致发送端无法正常收到保活探测报文的响应。那么在一定探测时间间隔tcp_keepalive_intvl后将继续发送保活探测报文。直到收到对端的响应或者达到配置的探测循环次数上限tcp_keepalive_probes都没有收到对端响应这时对端会被认为不可达TCP连接随存在但已失效需要将连接做中断处理。
HTTP keep-alive
keep-alive机制若开启后在一次http请求中服务器进行响应后不再直接断开TCP连接而是将TCP连接维持一段时间。在这段时间内如果同一客户端再次向服务端发起http请求便可以复用此TCP连接向服务端发起请求并重置timeout时间计数器在接下来一段时间内还可以继续复用。这样无疑省略了反复创建和销毁TCP连接的损耗。
TCP队头阻塞和HTTP队头阻塞
1. TCP队头阻塞TCP数据包是有序传输中间一个数据包丢失会等待该数据包重传造成后面的数据包的阻塞。停止等待2. HTTP队头阻塞http队头阻塞和TCP队头阻塞完全不是一回事。http1.x采用长连接(Connection:keep-alive)可以在一个TCP请求上发送多个http请求。有非管道化和管道化两种方式。非管道化完全串行执行请求-响应-请求-响应…后一个请求必须在前一个响应之后发送。管道化请求可以并行发出但是响应必须串行返回。后一个响应必须在前一个响应之后。原因是没有序号标明顺序只能串行接收。管道化请求的致命弱点:
会造成队头阻塞前一个响应未及时返回后面的响应被阻塞请求必须是幂等请求不能修改资源。因为意外中断时候客户端需要把未收到响应的请求重发非幂等请求会造成资源破坏。
由于这个原因目前大部分浏览器和Web服务器都关闭了管道化采用非管道化模式。无论是非管道化还是管道化都会造成队头阻塞(请求阻塞)。解决http队头阻塞的方法1. 并发TCP连接浏览器一个域名采用6-8个TCP连接并发HTTP请求2. 域名分片多个域名可以建立更多的TCP连接从而提高HTTP请求的并发3. HTTP2方式http2使用一个域名单一TCP连接发送请求请求包被二进制分帧**多路复用**不同请求可以互相穿插避免了http层面的请求队头阻塞。但是不能避免TCP层面的队头阻塞。
UDP
UDP如何实现可靠传输
传输层无法保证数据的可靠传输只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式只是实现不在传输层实现转移到了应用层。最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理可靠UDP的简单设计。
添加seq/ack机制确保数据发送到对端添加发送和接收缓冲区主要是用户超时重传。添加超时重传机制。
详细说明发送端发送数据时生成一个随机seqx然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存并发送一个ackx的包表示对方已经收到了数据。发送端收到了ack包后删除缓冲区对应的数据。时间到后定时任务检查是否需要重传数据。 原文作者一起学嵌入式
