40 | 案例篇：网络请求延迟变大了，我该怎么办？

[D40打卡] 我之前理解的网络延迟分三部分：客户端到服务端，服务端逻辑处理，服务端到客户端到耗时。 其中服务端逻辑处理的耗时是跟自身程序有关的，另外两个耗时跟宽带服务提供商有关，想更短的耗时就得加钱：选更优的线路或者在靠近客户端的地方加入口。 目前我们线上程序是可以推算出单次响应的时间的，因为在出入口的地方有记录。不管中间经过了多少服务的处理，都可以算出总的耗时。 我们在客户端中也加了汇报功能，在客户端的某些消息中会汇报 客户端实际发送请求->收到服务端响应 的时间差。这样便于我们确认客户端的网络状况。 从本文中，第一次见到了 Nagle 算法。也知道了服务端关闭icmp时怎么用tcp/udp测试网络延迟。 文中的内容也是跌宕起伏，分析着怎么还是客户端的问题，客户端访问另外一个服务还是好的。原来是服务端程序也有问题，一个巴掌拍不响。😂

网上查了Nagle算法的定义：任意时刻，最多只能有一个未被确认的小段。所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。 对比80端口和8080端口的报文，80端口的报文中，响应消息再发送完header后立刻发送body部分；8080端口的报文，响应消息再发送完header后，需要获得ACK响应后，才会发送body部分。 8080端口报文中server端在获得到ACK响应后才发送body部分，就是因为Nagle算法必须确认这个数据块被收到的原因。client在40ms后发送ACK是因为客户端没有开启TCP_QUICKACK的缘故。 请问老师，这样理解，对吗？

额 第二次居然curl不通了。。18.04 的防火墙是ufw ,需要ufw allow 80/tcp

你好，我在网络编程中遇到一个问题， 我们用go语言做的服务调用其他HTTP服务器，发现HTTP请求中卡住，概率非常低。 然后我看了发现write，返回eagain，然后就等待epoll通知描述符是否可用，这个时候发现等了很久很久都不可用。netstata看了下，TCP写buffer有数据但是没有满，等了很久也貌似发生不出去，有重传，但是还是传不出去。直接达到rto次数内核中断连接。 我们只能将rto改很小让内核中断连接。 请问这种情况一般都是由什么原因引起的呢？

我记得之前碰到的延迟ack是200ms，这个是可以配置的吗？

案例中能设置客户端的TCP_QUICKACK解决吗？

您好，请教下。我通过客户端直接访问服务器，平均响应延迟是30ms，经过nginx代理响应延迟是200ms，我使用的ngx+lua，业务逻辑是先查询worker进程的缓存，没有再查redis，再没有查mysql，现在lua层面可以优化的已经优化了，平均响应延迟还是170ms,不知道通过什么工具能定位具体哪里导致响应延迟慢呢？谢谢！

为什么执行strace -f wrk --latency -c 100 -t 2 --timeout 2 http://192.168.126.136:8080/，输出结果中并没有TCP_NODELAY配置选项呢？

同一套环境碰到一个低并发高延时，高并发低延时得的问题，请问倪老师像这种问题该如何排查?

traceroute 会在路由的每一跳发送三个包，并在收到响应后，输出往返延时。如果无响应或者响应超时（默认 5s），就会输出一个星号。 ----这个地方，还有些不明白，希望老师能在这里再解释几句