全面了解TCP/IP知识体系结构总结(干货)

gk-auto

tcp/ip系列知识分享完毕，之后会分享一些工作中的典型网络案例和troubleshooting过程。

后续还会出一个postgresql从小工到大牛的系列专辑文章。

废话不说，直接干货。

TCP知识体系

我们从三个维度去分析服务器开发的TCP知识体系，分别为性能法则、设计法则和避坑法则。

性能法则

性能法则大致总结如下：

• 减少数据传递
  

下面引用了左耳朵的"程序员如何用技术变现"文章中的一部分：

从上面我们可以看出减少数据传递对于性能是非常重要的。

• 根据场景设置MTU
  

如果是内网应用，通过合理设置MTU来提升性能是不能忽视的一种手段；对于移动应用，一般可以设置MTU为1492；对于外网应用，则设置通用的1500。

• 利用TCP offload
  

带宽消耗高的应用，可以考虑利用TCP offload来提升性能。

• TCP NODELAY
  

目前服务器程序一般建议设置NODELAY为true，如果需要对小数据包合并，则可以考虑在应用层做数据合并（参考下图Wikipedia中内容）。

详细内容请参考："
https://en.wikipedia.org/wiki/Nagle%27s_algorithm"

• 采用合适的拥塞控制算法
  

下图展示了数据包经过路由器Queue的场景。

第一种是最理想的情况，数据包到达路由器，无需等待就能直接转发出去；第二种是等待一段时间，才能发送出去；第三种是因为路由器queue满，数据包被路由器丢掉。

发送数据过猛可能导致第三种情况发生。

下面展示了Linux默认算法CUBIC和BBR算法在丢包情况下的吞吐量对比：

从上图可以看出，BBR拥塞控制算法可以在20%丢包率以下保持吞吐量，因此BBR的抗网络抖动性比CUBIC要好。

BBR算法优异的根本原因如下：

1. 在有一定丢包率的网络链路上充分利用带宽

2. 降低路由器的queue占用率，从而降低延迟

一般建议在非网络拥塞导致丢包的场合使用BBR算法，例如移动应用。

对于带宽比较大，RTT时间比较长的应用场景，可以参考。

• 使用REUSEPORT
  

针对短连接应用（例如PHP应用），为防止服务器应用来不及接收连接请求，可以采用Linux REUSEPORT机制。我们开发的数据库中间件Cetus利用REUSEPORT机制成功避开了应用短连接的冲击。

3、设计法则

• 规避TCP HOL问题
  

尽量采用多连接，不要采用单个连接来传递大量数据。

• 传输尽量平稳，不抖动
  

如果数据传输比较抖动，那么容易导致如下问题：

1. 内存膨胀

2. 性能不稳定

3. 压缩算法效率低下

在开发数据库中间件Cetus的时候，我们控制了每次数据传输的传输量，在采用同样压缩算法的情况下，cetus压缩比远远好于MySQL的压缩比。

• TCP stream流式传输
  

TCP stream主要用在中间件服务。

下图是没有采用TCP stream的交互图。中间件接收完Server端的响应后，才开始发送给客户端。不少数据库中间件采用这样的工作方式，导致中间件内存消耗巨大。

下图采用了TCP stream方式后，不仅降低了延迟，也降低了内存消耗（因为无需保留所有响应）。

服务器中间件程序最好实现TCP stream，否则易发生内存炸裂等问题。

• 上层应用pipeline机制
  

TCP本身并不具备pipeline机制，但上层应用可以利用pineline机制来提升服务器应用的吞吐量。

下图是没有采用pipeline的交互图，客户端需接收到服务器响应后才能发送下一个请求。

下图是采用pipeline的交互图。客户端无需等待响应就可以连续发送多个请求。

对于TCP来说，请求1、请求2和请求3看成一个请求，响应1、响应2和响应3看成一个响应；对于上层应用来说，则是3个请求，3个响应。

目前，很多协议或者软件采用pipeline机制来提升应用的吞吐量，例如HTTP v2协议支持pipeline发送请求，Redis采用pipeline机制来提升应用的吞吐量。

• 合并小数据
  

运行TCPCopy的时候，intercept返回响应包的TCP/IP header给tcpcopy。一般TCP/IP header只有几十字节，如果每次write操作只传输一个响应包的TCP/IP header，那么效率就会非常低。为了提升传输效率，intercept合并若干个响应包的TCP/IP header信息一起发送。

4、避坑法则4.1 加上keepalive机制

TCP keepalive机制可以用来检测连接是否还存活，具体可以参考"对付Reset流氓干扰：TCP keepalive"。

• MTU
  

参考:"
https://wiki.archlinux.org/index.php/Jumbo_frames"

• 确保网络通畅
  

云环境、中途设备程序、TCP offload和负载均衡器或多或少存在一些问题，而这些问题如果不及时解决，会极大影响程序的性能和问题排查。

这方面一般可以通过抓包的方式去查明问题。

下面展示了负载均衡器自身bug导致了网络不通畅。

由于负载均衡器没有严格按照TCP session的方式进行负载均衡，有些TCP session的数据包跑到了不同的机器，进而导致应用端报请求超时。

最初连接<client IP:xxx.xxx.152.2,client port:52481,server IP:yyy.yyy.195.137,server port:443>的数据包跑到了180机器。

后来这个连接的数据包跑到了176机器（参考下图）。

负载均衡器出现这种bug，会造成用户的极大困扰，很难查明问题原因。

这时要么更换负载均衡器，要么找厂商解决负载均衡器的bug，否则上层应用会一直报网络超时等问题。

5、总结

对于服务器开发人员，只有了解了TCP知识体系后，开发起来才能够得心应手，同时可以规避一些潜在的坑。

来源：架构师之路（头条）

原文链接：https://www.toutiao.com/a6730411681177928204/

952867072

感恩无私的分享与奉献

哥哥叫国栋

论坛有你更精彩！

sgjw1

赞同 + 10086，没毛病，完全没毛病

wx_mAyARY7Q

蹲一波同款，有没有姐妹 / 兄弟推荐？

书海

说得对！狠狠赞同，没毛病～

laowang

不请自来，就想夸一句：太顶了！

deardavid13

蹲一波同款，有没有小伙伴推荐？

llll_0321

赞同 + 10086，完全说出了我的想法！

hhhxxx

这波分析到位，逻辑满分！