摘要：目的：验证接收缓冲区是每个channel都有一个，而不是共用一个 策略：在读缓冲区（滑动窗口）耗尽与write阻塞、拆包、延迟（一）的基础上，服务端设置100的接收buf（实际腾讯云系统会放到1152），客户端设置100的发送buf； 先开一个客户端，发送12个包后阻塞，此时再开第2个客户端，看看其
阅读全文
摘要：在读缓冲区（滑动窗口）耗尽与write阻塞、拆包、延迟（三）中，tcpnodelay+no so_linger 18读缓冲区（滑动窗口）耗尽与write阻塞、拆包、延迟（四）linger中，tcpnodelay+so_linger true 0 本文 tcpnodelay+so_linger tru
阅读全文
摘要：https://bbs.csdn.net/topics/380166111 及《java网络编程精解》p42页都说close可能阻塞 本文实践： 结论： 1 fin在1s以内就发出了，close未阻塞 2 5s内，5s后 JoycedeMacBook:netty-test joyce$ netsta
阅读全文
摘要：linux环境， cat /etc/redhat-releaseCentOS Linux release 7.5.1804 (Core) ulimit -n100001 sysctl -a | grep fs.file-nr 832 0 183945 1 纯文件 file.jar 1.1 ulimi
阅读全文
摘要：在21Why httpclient is recommended to go with a connection pool in server-to-server request?中阐述了文件描述符耗尽导致异常，本文予以证明 mac环境 ulimit -n10240 sysctl -a | grep
阅读全文
摘要：在上一节中，我们发现（三）情况是典型的4次挥手场景，却没有成功，这不是与4次挥手相悖么 原来，https://www.cnblogs.com/exmyth/p/8204724.html 前面说到出现“Connection reset”的原因是服务器关闭了Connection[调用了Socket.cl
阅读全文
摘要：（一）false read [root@VM_0_9_centos ~]# java -jar netty-in-action-0.1-SNAPSHOT-jar-with-dependencies.jar1false 5s内 JoycedeMacBook:netty-test joyce$ nets
阅读全文
摘要：在读缓冲区（滑动窗口）耗尽与write阻塞、拆包、延迟（三）中，程序退出了，tcp协议还在自己跑，关键是SO_LINGER参数 默认-1，则会等发送缓冲区发完才发压箱底的fin，true时，会直接关闭连接，本文予以验证 由于发送缓冲区默认巨大，客户端输出： 131072131072-1send +
阅读全文
摘要：https://www.cnblogs.com/diaobiyong/p/9929319.html#p4.4.1 这个链接中4.1，通过客户端绑定端口，出现了客户端第2次起点报端口占用，本文予以实践（mac本地环境）： public class Server { public static fina
阅读全文
摘要：在13发送缓冲区、滑动窗口 对小于mss的包是如何拆包的的代码上，在10tcp缓冲区大小设置的理论基础上 为了使包>mss（一般1460），发送端将包的大小1300-》1600 为了避免由于接收窗口而拆包，接收端setReceiveBufferSize由100-》3000 保持发送缓冲区为默认，避免
阅读全文
摘要：2个大原则 1 read只是拷贝不是接收 2 write只是拷贝不是发送 第14篇文章的案例——发送端使用默认发送缓冲区大小，接收端不read，即能证明这两点，前12秒接收端没read，包也过去了直到窗口不够，而此时发送端一直继续write，虽然包没出去 1关于tcp delayedack实践（一）
阅读全文
摘要：本文设计了一个案例，证明禁用nagle的情况下，并非所有情况都不会导致发送端沾包 在 读缓冲区（滑动窗口）耗尽与write阻塞、拆包、延迟（二）的代码上，使用默认发送缓冲区大小，并禁用nagle，这是第三种情况，前2种在11读缓冲区（滑动窗口）耗尽与write阻塞、拆包、延迟（一）中 服务端，12s
阅读全文
摘要：由于在之前的例子中，我们可以看到腾讯server返回的mss都是1460，windowsize 1152（接收端读缓冲，发送端写缓冲），故我们设计包大小为1300，以体现超过1152缓冲区的包，会被拆包，另外我们将客户端写入缓冲区分别设置为100和1300 1 先考虑发送缓冲区拆包，写入缓冲区100
阅读全文
摘要：在读缓冲区（滑动窗口）耗尽与write阻塞、拆包、延迟（一）上一篇中，我们让服务端不读，这一篇中，让她等12s再读，看看滑动窗口变化通信 代码不变，server 启动时 +参数12 结论： 1 为什么sleep 12s，因为要与客户端阻塞后每5s发送一次的询问区分开 2 到25号报文，服务端告诉客户
阅读全文
摘要：本文验证window耗尽（读缓冲区、滑动窗口） server： client: 这里以 0+100 模式的日志为例： server输出 43690 /183.195.35.246:21199 client输出 131072 131072 send + 0 send + 1 send + 2 send
阅读全文
摘要：在 socket用户缓冲区、socket内核缓冲区与tcp协议buffer（滑动窗口）的关系 中，我们最主要的，认为java socket的缓冲区即是tcp滑动窗口 本文予以实践认证 在之前的例子代码中，socket缓冲区与沾包 nagle in tcp，两边加上s.getReceiveBuffer
阅读全文
摘要：在netty粘包（一）消息定长 实践中，netty出现沾包，用了FixedLengthFrameDecoder(14)解决沾包，本次将FixedLengthFrameDecoder(14)干掉，然后抓包看是什么原因导致沾包，是客户端搞在一起了，还是服务端没有及时取走导致沾包 server: serv
阅读全文
摘要：https://blog.csdn.net/kdy527/article/details/85106657 该链接中，认为： 服务端与客户端建立连接后，服务器端先向缓冲区写入两条信息，在第一条信息写入时，缓冲区并未写满，因此在第二条信息输入时，第一条信息很可能还未发送，因此两条信息可能同时被传送到客
阅读全文
摘要：上一篇关于tcp delayedack实践（二）http中，实践了一条http长连接，4次请求响应，应证了关于tcp delayedack实践（一）tcp中 “http短链接不会deleyed ack，但请注意，微服务中的长连接就有这样的情况了”，比如包太长被分了，这个例子好在http reques
阅读全文
摘要：使用netty（五）http服务中的服务代码 tcpdump -i eth0 tcp and port 8990 -s 0 -w traffic.pcap 三次握手+http+四次挥手，应证了——［专项］tcp状态机，为什么3次握手（很好）(done) 可以看到，断开连接时，本例中ack与fin放在
阅读全文
