文章目录问题现象定位过程虚机端主机端基础知识HTTPTCPIP
问题客户云主机每隔一段时间使用curl工具获取http服务器端的信息，通常可以正常运行。 如下图所示，如果多次使用同一个curl命令，则curl可能会被卡住一次，导致命令没有回复。 用户反馈通过使用其他网络线路节点上的虚拟机访问相同的http服务，并且不出现。 照片里藏着ip和port。
在对齐过程的虚拟机端，首先使用strace命令显示包含curl命令的用户堆栈，如下所示：
curl工具实际上用于模拟http协议的request，可以发送http请求，如GET/PUT/POST。 如果不指定curl方法，缺省情况下将发送GET请求。 正如strace工具所看到的，curl在发送http request时使用套接字接口启动tcp连接服务器端。 上图中隐藏了服务器端的地址和端口。 可以看到curl卡在了connect之后的poll上。 在检查curl进程的状态并调用poll接口后，进程休眠如下：
在确认内核堆栈实际处于休眠状态并由服务器响应并返回tcp包之前，不会启动curl进程。
主机端在执行curl命令时将包抓住主机端的虚拟机vnet网卡，然后使用命令tcpdump-nni $ { eth } host $ { IP } and port $ { port }。 正常运用时的包如下。
curl堵塞时的数据包如下，比较可以看到curl堵塞时ip报文卡通过tcp次握手的第一个握手sync数据包。 根据左边的时间戳，可以确认重新发送了sync包，tcp重新发送的时间指数增加了：1、2、4、8、16、32。
获取链路层数据，进一步分析sync数据包的内容。 tcpdump-nnxi $ { eth } host $ { host } and port $ { port } :
通过以上分析，可以确认云主体内部的curl命令被卡住的原因是主体端开始tcp连接时发送的sync数据包被卡住，服务器端没有ack数据包的响应，所以一直在重复发送。 虚拟机内部出现的现象是curl一直被堵塞。 现在，我们看到虚拟机流量至少来到了主机的vnet端。 下一步，需要验证通信是否来自物理网卡，查看vnet网桥的ovs网桥，并找到相应的物理端口。 1 .显示1. virsh domiflist vm虚拟机vnet桥的ovs桥包括： 通过br-int2. ovs-vsctl show显示主机上的ovs网桥信息和其上的port3. ovs-of CTL-o openflow 13 show br-int显示br-int的虚机vnet端口支持ovs网桥找到sbr-int，导出OVS上的流表，检查其传输规则，发现output抓住消息，tcpdump-nneei${eth}heth}也是sync数据包为什么服务端不做ack应答，有两种可能性。 链路丢包且完全未到达服务端，宿主机发送tcp协议后计数器超时，自动重传链路到达服务端，但服务端cpu忙或http服务器处理有问题触发自动重传的基础知识HTTP http协议既可以用于实现网络资源的操作和访问，也可以使用cs模式传输内容，将传输的两端分别作为客户端工具和服务端的web APP应用其形式如下。
在我们的案例中，curl是组装http请求的工具，如果不指定method，则缺省为GET，内容如下。
http协议的内容作为tcp协议的payload存在，curl在发送http请求时首先与服务端建立tcp连接，我strace跟踪的connect系统调用通过socket编程连接到服务端tcp连接的核心工作是三次握手，三次握手结束后建立连接。 然后，curl工具可以将http的内容写入tcp连接的buffer，并传输到服务器端。 服务端读取tcp的内容，从中解析http的数据后，传递给上层的web服务器程序。 由此，实现了http协议内容的传输。 传输完成后，curl将断开此tcp连接。 对于http，所有tcp协议都用于短连接，并且每次提交请求时都会断开tcp连接。 tcp tcp协议的两端是APP，linux上的下一个tcp连接通过套接字编程接口监听tcp的服务端，在每次数据到达端口时进行解析，然后做出相应的响应。 其形式如下。
使用tcpdump工具解析tcp协议的头部，将使用tcpdump-itap 42 a4 a5 cc-1a-nn xhost 10.251.53.131 and port 8890-vv在三次握手期间发送的tcp消息解析为
在tcpdump的信息中，大部分字段是明确的。 以下只分析Flags和options这两个字段。 Flags区域分析tcp头部的Flags，用可读取的文字表示。 手册说明如下。 tcpflagsaresomecombinationofs (syn )，f ) )。 r(rst )，u ) urg )、w(ECNcwr )、e(ECN-ECHO ) or `.' (ack )、or ` none ' if no flags are set syn :是三次握手中的同步数据包
接，这个包只有头部，没有数据。FIN: 表示四次挥手中的结束包，用于关闭tcp连接，这个包只有头部，没有数据。PUSH: 表示tcp协议中有数据，tcp的payload不是空的，这是真正传输数据的包。如果上层是http协议，那么它传输的就是http协议的内容，当目的端的socket的server接收到tcp连接传输的数据后，它将tcp承载的内容解析出来，交给上层的web server，web server按照http协议约定解析相关字段，进行对应处理。ACK: 标识回复包，除了连接建立时第一次握手syn包不带ACK标识，其余任何时候的包都带有ACK标识，用于告诉对端自己希望收到的下一个包的起始序号，为表示方便就用一个.代替ACK标识。 options字段长度可变，在0~40字节范围内，用于实现一些测试和验证的功能，下面介绍几个常见的option，更多细节参考TCP协议: MSS: Max Segment Size，用于设置tcp协议中能够发送的最大报文长度，这里的长度指的时tcp的payload，需要减去tcp头部长度，通常是MTU-40（减掉的这40字节包括20字节的TCP头部和20字节的IP头部）。TS val: Timestamps value，记录发送方在发送报文是当前系统的时间戳，这样可以计算整个包到达目的端的耗时，从而计算往返时间（Round-trip time）。wscale: Window Scale，早期的tcp协议中，接受窗口大小的最大值为65535字节，随着硬件能力的提升，能处理的窗口大小越来越大，可以进一步增大窗口大小，而tcp协议中给window size字段设计的长度是16bit，只能表示65535字节，为扩大窗口范围，给出了一个解决方案，在tcp协议的可选字段中增加wscale，表示window size的单位（窗口缩放因子）。在三次握手通信双方把自己的wscale告知对方，在正常通信解析window size时，将window size乘以2^wscale。假设wscale协商为7，如果window size的值为500，那么实际的窗口大小为500 * 2 ^ 7 = 500 * 128 = 64000。 IP IP报文不保证可靠连接，它的格式如下：下图为IP报文的内容分析：