具体通过如下命令获取zk的状态： echo stat | nc 192.168.73.77 2181 出现问题时，发现nc命令一直没有返回，导致无法执行后续的步骤（程序压根没启动）。...到zk上查看了对应的日志，也没有发现对应时间段有错误的打印。 既然zk都没有错误日志信息，那只能先分析下nc命令当前卡在哪里了。...内部处理流程本质上就是先建立tcp连接，然后循环处理socket上的可读可写事件，当有可读事件，并且长度为0（EOF）时，回调处理中标记退出循环，然后整个进程也就跟着退出了。...而长度为0的可读事件，是收到FIN后，内核协议栈往上发送的可读事件。 结合上面说的FIN_WAIT2，就可以知道nc命令为什么不退出了。...通过增加参数“+vvvvvv”查看nc命令执行过程中的输出，对比正常情况和异常情况，可以清楚的看到这一点： 正常退出的情况： 异常不退出的情况： 清楚了问题的所有环节，只剩下为什么nc命令没有收到
--滑动窗口 滑动窗口滑的过程中，他一直告诉我处理不过来了，不让传数据了怎么办？--ZWP 滑动窗口滑的过程中，他处理得慢，就理所当然的每次让我发很少的数据，导致网络利用率很低怎么办？...每个选项开始是1字节kind字段，说明选项的类型 kind为0和1的选项，只占一个字节 其他kind后有一字节len，表示该选项总长度（包括kind和len） kind为11，12，13表示tcp事务...同样的道理，主动关闭服务器，2MSL时间内立马启动是会报端口被占用的错误 多并发的短连接情况下，会出现大量的Time_wait状态。这两个参数可以解决问题，但是它违背了tcp协议，是有风险的。...服务器对于并发请求的处理 正等待连接的一端有一个固定长度的队列（长度叫做“积压值”，大多数情况长度为5） 该队列中的连接为：已经完成了三次握手，但还没有被应用层接收（应用层需要等待最后一个ack收到后才知道这个连接...，ACk是累计的，它表示接收方已经正确收到了一直到确认序号-1的所有字节 延时时间：绝大多数为200ms。
len 传入的地址长度，bind函数会根据该字段判断传入的参数addr怎么解析。...两个socket描述字： 输入参数，监听socket描述字listensockfd 返回的已连接socket描述字 为什么要把两个套接字分开呢？...客户端收到了RST（复位）回答，这时候客户端会立即返回CONNECTION REFUSED错误。...形象一点的比喻是这样的，有A和B想进行通话： A先对B说：“喂，你在么？我在的，我的口令是j。” B收到之后大声回答：“我收到你的口令j并准备好了，你准备好了吗？我的口令是k。”...A收到之后也大声回答：“我收到你的口令k并准备好了，我们开始吧。” 可以看到，这样的应答过程总共进行了三次，这就是TCP连接建立之所以被叫为“三次握手”的原因了。
这个SYN 包的 seq 为0。这是第一次握手。 当服务端接收这个 SYN 包时，知道了有人要连接自己，就发了一个 ACK 包说：你要连接这件事，我已经知道啦。...关于 为什么需要握手（注意：这里还没开始讨论为什么要三次握手），我认为应该有两个理由： 同步起始序列号，为后续数据传输做准备 保证双方都可能发送数据且能接收数据 关于第一点，其实两次握手就可以，客户端把自己的...我：“可以呀” # 没有向对方确认是否可以听到自己就开始一直说说说 我：“你吃饭了吗？“ 我：“人呢？“ 我：“喂？“ 我：“去哪啦？...在每一次跟确认可以听到对方的声音时，还生怕这个消息对方收不到这个消息，所以两个人就一直在确认，跟个zz一样。 所以你问我，为什么不握手五次或更多？...socket 其中参数backlog作用 设置内核中队列的长度 。
4、TCP 服务是基于流的，而 UDP 是基于数据报的，基于流的数据没有边界（长度）限制，而基于数据报的服务，每个 UDP 数据报都有一个长度，接收端必须以该长度为最小单位将其所有内容一次性读出。...3、发送端接收到确认信息，再发回给接收端，表示我已接受到你的确认信息，此时标志仍为 ACK，确认序号为 522。 涉及到的问题：为什么是三次握手，而不是四次或者两次？ 首先解释为什么不是四次。...很明显，接收方并不知道也不能保证发送方一定接收到 “好的” 这条信息，一旦接收方真的没有收到这条信息，就会出现接收收“单方面连接”的情况，这个时候发送方就会一直重试发送连接请求，直到真正收到 “好的”...涉及到的问题：为什么需要四次握手，不是三次？ 三次的过程是这样的： 发送方：我不再给你发送数据了。 接收方：好的，我也不给你发了。 发送方：好的，拜拜。...) # 第三个参数，如果为0，也不可复用 # 第三个如果为1，可以复用 # s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind(
connect函数的第一个参数即为客户端的socket描述字 第二参数为服务器的socket地址，第三个参数为socket地址的长度。客户端通过调用connect函数来建立与TCP服务器的连接。...socket描述字； 第二个参数为指向struct sockaddr *的指针，用于返回客户端的协议地址； 第三个参数为协议地址的长度。...当读成功时，read返回实际所读的字节数; 如果返回的值是0表示已经读到文件的结束了，小于0表示出现了错误。 如果错误为EINTR说明读是由中断引起的，如果是ECONNREST表示网络连接出了问题。...1)write的返回值大于0，表示写了部分或者是全部的数据。 2)返回的值小于0，此时出现了错误。我们要根据错误类型来处理。如果错误为EINTR表示在写的时候出现了中断错误。...该函数的第一个参数指定接收端套接字描述符； 第二个参数指明一个缓冲区，该缓冲区用来存放recv函数接收到的数据； 第三个参数指明buf的长度； 第四个参数一般置0。
要知道，端口资源也是有限的，一般可以开启的端口为 32768~61000 ，也可以通过如下参数设置指定范围： net.ipv4.ip_local_port_range 那么，如果如果主动断开连接方的...，造成数据传输错误。...accept() 的 TCP 连接个数； Send-Q：当前 accpet 最大队列长度，上面的输出结果说明监听 8088 端口的 TCP 服务进程，accpet 队列的最大长度为 128； 如果 Recv-Q...要解决这个问题，我们可以： 调大 accpet 队列的最大长度，调大的方式是通过调大 backlog 以及 somaxconn 参数。...检查系统或者代码为什么调用 accept() 不及时； 关于 SYN 队列和 accpet 队列，我之前写过一篇很详细的文章：TCP 半连接队列和全连接队列满了会发生什么？又该如何应对？
确认号：即ACK，指明下一个期待收到的字节序号，表明该序号之前的所有数据已经正确无误的收到。确认号只有当ACK标志为1时才有效。比如建立连接时，SYN报文的ACK标志位为0。...由于首部可能含有可选项内容，因此TCP报头的长度是不确定的，报头不包含任何任选字段则长度为20字节，4位首部长度字段所能表示的最大值为1111，转化为10进制为15，15*32/8=60，故报头最大长度为...首部长度也叫数据偏移，是因为首部长度实际上指示了数据区在报文段中的起始偏移值。 保留：占6位，保留今后使用，但目前应都位0。...为什么会采用三次握手，若采用二次握手可以吗？ 四次呢？ 建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。...采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。
所以，边缘触发模式一般和非阻塞 I/O 搭配使用，程序会一直执行 I/O 操作，直到系统调用（如 read 和 write）返回错误，错误类型为 EAGAIN 或 EWOULDBLOCK。...讲一下多态的理解 答：多态的话，我的理解是函数重载和虚函数，函数重载的好处我认为是同一个函数名可以对不同的参数类型或者参数个数进行不同的实现；虚函数我认为是可以使得子类在继承父类的时候，基于子类的特点重写父类的一些函数...答：我认为应该可以 为什么呢，你对引用的理解是什么？ 答：因为我认为引用其实相当于变量的地址值，类似一个指针。 那么引用是不是可以理解为const的一个指针？...答：1 为什么呢？ 答：我就说了C++是固定地址的，如果是0的话，调用的时候会有地址冲突。 说到这个sizeof，你觉得它是函数吗？ 答：它是运算符 运算符的话，一般在什么时候给它定好？...但是上限值是内核参数 somaxconn 的大小，也就说 accpet 队列长度 = min(backlog, somaxconn)。 怎样设置一个套接字为非阻塞模式？
我直接给出结论吧，可以被加密的字节长度与密钥的比特数呈线性正相关，我们有如下公式： ? 我上次设置的密钥比特数是256，最大长度也就是256/8-11=21。...下面我来重点解决这个问题，为什么会出现粘包？...，从而不会出现接收到多余的无用的数据。...["data_size"] # 获取字典的value，也就是真实数据长度 block_list = [] # 接收数据的容器 recv_size = 0 # 接收到的数据长度...命令执行有两种结果，正确和错误，正确的结果在标准输出流stdout中，错误的输出结果在标准出错流stderr中，我们直接对输出重定向，将结果直接写入文件。然后就是读取文件，发送数据。
A发送断开消息给B，B回一条消息表示我收到了，这个过程就保证了A断开成功。B发送断开消息给A，A回一条消息表示我收到了，这个过程就保证了B断开成功。...服务器收到请求，需要请求者继续操作。 2XX - 请求成功。请求成功收到，理解并处理。 3XX - 重定向。需要进一步的操作以完成请求。 4XX - 客户端错误。请求包含语法错误或无法完成请求。...所以一般要在请求头中设置Connection字段的值为：keep-alive，表示维持连接不要断开，一直到某个数据包的Connection字段的值为close。...使用方法： 消息头部设置Transfer-Encoding: chunked 每一块会表明长度 由一个标明长度为0的chunk标示结束 目的： 让客户端快速响应，减少等待时间。维持长连接。...通过设置content-type为multipart/form-data，来发送二进制格式文件。支持多个文件上传，还可以带上文本参数。 这种是最常见的做法。
那协议栈收到了这一堆二进制序列之后是不是就直接交给网卡发送了呢？ 我都这么问了，那显然不是了... 其实协议栈在收到数据之后并不会马上就会就发送出去，而是会先写入位于内存的 Buffer 中。...例如我发这篇文章时所发请求的数据长度就可能超过 MSS 。 此时就需要对数据进行拆分，按照 MSS 的长度为单位进行拆分，将拆出来的数据分别装进不同的数据包中。...这些发送过的包都会暂存在 Buffer 中，如果传输的过程中出错，则可以进行重发的补偿措施。这也是为什么在数据链路层（例如网卡、路由器、集线器）等等都没有补偿机制，它们一旦检测到错误会直接将包丢弃。...那 TCP 不就一直无限循环的把请求发下去了？ 当然 TCP 设计时也考虑到了这种情况，其在重传几次无效之后，就会强制中断通信，并抛出错误给应用程序。...接收方会在确认应答的时候，将自己的剩余窗口大小写入，随ACK一起发送给发送方。 如果发送方接收到的大小为0，那么此时就会停止发送数据。
那协议栈收到了这一堆二进制序列之后是不是就直接交给网卡发送了呢？ 我都这么问了，那显然不是了... 其实协议栈在收到数据之后并不会马上就会就发送出去，而是会先写入位于内存的 Buffer 中。...例如我发这篇文章时所发请求的数据长度就可能超过 MSS 。 过长数据包拆分 此时就需要对数据进行拆分，按照 MSS 的长度为单位进行拆分，将拆出来的数据分别装进不同的数据包中。...这些发送过的包都会暂存在 Buffer 中，如果传输的过程中出错，则可以进行重发的补偿措施。这也是为什么在数据链路层（例如网卡、路由器、集线器）等等都没有补偿机制，它们一旦检测到错误会直接将包丢弃。...那 TCP 不就一直无限循环的把请求发下去了？ 当然 TCP 设计时也考虑到了这种情况，其在重传几次无效之后，就会强制中断通信，并抛出错误给应用程序。...接收方会在确认应答的时候，将自己的剩余窗口大小写入，随ACK一起发送给发送方。 TCP流量控制 如果发送方接收到的大小为0，那么此时就会停止发送数据。
，如IP地址、端口 TCP是一种字节流，它会处理IP层的丢包、重复以及错误问题 在建立连接的过程中，双方交换的一些参数可以放到TCP的头部 总结 ：TCP提供了一种可靠、面向连接、字节流、传输层的服务...为什么是三次冗余ACK 通过大量经验表明三次比较合适 为什么不进行两次握手 1、确认双方的接收与发送能力是否正常 第一次握手：客户端发送网络包，服务端收到了。...服务端：服务端的发送能力，客户端的接收能力正常 2、防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误 如果客户端发出连接请求，因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求...，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且重启2MSL计时器 2、防止类似与”三次握手中提到了"已经失效的请求报文段...服务器每收到一个客户端的请求后都会复位这个计时器，时间通常设置为2小时，若超时后还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75s发送一次。
的数据报，长度是100，下一次确认号则为601 数据偏移： 占4位：0~15，单位为：32位字（由此可以看出最大偏移为15*4，即TCP首部长度介于20-60个字节之间） 数据偏离首部的距离 不知道TCP...，发送方一直等到对方窗口变大，接收方一直等待对方发送消息 坚持定时器（解决死锁）： 当发送方接收到窗口为0的消息，则启动坚持定时器 坚持定时器每隔一段时间发送一个窗口探测报文 这种死锁相当于情侣一方A一直等待对方...即发送方状态为：同步已发送、建立连接。接收方状态为：监听、同步已接收、建立连接 最早，接收方和发送方都是closed状态，即关闭。 为什么发送方要发出第三个确认报文（为什么需要第三次握手）？...（第一次超时）就会建立起两个连接，引起错误 本来这是一个早已失效的报文段,但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。...虚线是假设两次握手就建立连接 TCP连接的四次挥手 比三次握手多出来的是第二次挥手，意思是我收到了，但是我现在还没传完，等会关闭 主动关闭的一方状态变化为：建立状态、第一次等待(FIN-WAIT-1)
序号：用于对字节流进行编号，例如序号为 301，表示第一个字节的编号为 301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401。 确认号：期望收到的下一个报文段的序号。...例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701。...1、第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。 2、换个易于理解的视角来看为什么要 3 次握手。...： 消息定长：发送端将每个数据包封装为固定长度（不够的可以通过补 0 填充），这样接收端每次接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。...接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
，recv函数就把s的接收缓冲中的数据copy到buf中（注意协议接收到的数据可能大于buf的长度，所以在这种情况下要调用几次recv函数才能把s的接收缓冲中的数据copy完。...参数释义： 参数一：指定接收端套接字描述符； 参数二：指明一个缓冲区，该缓冲区用来存放recv函数接收到的数据； 参数三：指明buf的长度； 参数四 ：一般置为0。...参数一：指定发送端套接字描述符； 参数二：存放应用程序要发送数据的缓冲区； 参数三：实际要发送的数据的字节数； 参数四：一般置为0。...char buffer[128]; buffer[128] = '\0'; 通过 recv 读取的字符数为 128 时，就会是文稿中的结果。...-1 : 0; return rc; } 在进行报文解析时，第 15 行对实际的报文长度msg_length和应用程序分配的缓冲区大小进行了比较，如果报文长度过大，导致缓冲区容纳不下，直接返回
其中10.128.x.x是rs的ip，10.115.x.0/24是dpvs的local ip，通过在rs上的抓包结果可以清楚的看出rs发给dpvs的length为184的包正确传输，但length为...2的包一直在重传，且直至超时都没有成功，同时在client上的抓包显示，client收到了这个length为2的包，但是由于tcp checksum error被丢掉了，并没有交给上层应用去处理，这样就解释了为什么异常时的表现是...+ tcp data = 14 + 20 + 20 + 5 = 59，而我们知道，在网络中传输的数据帧最小长度为64字节，除去FCS的4字节（这部分也由网卡自行计算后添加在数据包末尾），最小长度应为60...对此rfc894是这样规定的： 因此rs的网卡在数据包长度不足60字节时需要做两件事情： 补充1字节的padding达到最小长度60字节 补充的padding为全0 可以看到，在二层头中，确实有个补充的...计算错误，client收到后丢弃了这个包 ps：以上是rs的网卡在添加padding时补充的不是全0，另一种场景是client的网卡在添加padding时补充的不是全0，这两种情况都会导致上述问题的出现
请问这种错误如何避免。是否要在 recv之前，判定连接是否中断，如果未中断则recv. 恩。我最后查了一下，是因为服务端关闭了套接字，才导致这边recv返回0。...该函数的第一个参数指定接收端套接字描述符； 第二个参数指明一个缓冲区，该缓冲区用来存放recv函数接收到的数据； 第三个参数指明buf的长度； 第四个参数一般置0。...当协议把数据接收完毕，recv函数就把s的接收缓冲中的数据copy到buf中 （注意协议接收到的数据可能大于buf的长度，所以 在这种情况下要调用几次recv函数才能把s的接收缓冲中的数据copy完。...返回说明： 成功执行时，返回接收到的字节数。 另一端已关闭则返回0。...：sock索引的不是套接字 当返回值是0时，为正常关闭连接； 思考： 当对侧没有send，即本侧的套接字s的接收缓冲区无数据，返回值是什么（EAGAIN，原因为超时，待测） http://hi.baidu.com
参数释义： 参数一：指定接收端套接字描述符； 参数二：指明一个缓冲区，该缓冲区用来存放recv函数接收到的数据； 参数三：指明buf的长度； 参数四 ：一般置为0。...参数一：指定发送端套接字描述符； 参数二：存放应用程序要发送数据的缓冲区； 参数三：实际要发送的数据的字节数； 参数四：一般置为0。...s的发送缓冲中的数据或者s的发送缓冲中没有数据，那么 send就比较s的发送缓冲区的剩余空间和len： （i）如果len大于剩余空间大小send就一直等待协议把s的发送缓冲中的数据发送完； （...，recv函数就把s的接收缓冲中的数据copy到buf中（注意协议接收到的数据可能大于buf的长度，所以在这种情况下要调用几次recv函数才能把s的接收缓冲中的数据copy完。...，那么它返回0。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
