脑残式网络编程入门(二)：我们在读写Socket时，究竟在读写什么？

1、引言

本文接上篇《脑残式网络编程入门(一)：跟着动画来学TCP三次握手和四次挥手》，继续脑残式的网络编程知识学习 ^_^。

套接字socket是大多数程序员都非常熟悉的概念，它是计算机网络编程的基础，TCP/UDP收发消息都靠它。我们熟悉的web服务器底层依赖它，我们用到的MySQL关系数据库、Redis内存数据库底层依赖它。我们用微信和别人聊天也依赖它，我们玩网络游戏时依赖它，读者们能够阅读这篇文章也是因为有它在背后默默地支持着网络通信。

本篇文章依然尝试使用动画图片的方式，来对这个知识点进行“脑残式”讲解（哈哈），期望读者们可以更加简单、直观地理解Socket通信的数据读写本质。

友情提示：如果您的网速较慢，加载gif动画可能较慢，请耐心等候哦。

* 推荐阅读：强烈建议同时阅读《深入操作系统，一文搞懂Socket到底是什么》、《深入操作系统，一文搞懂Socket到底是什么》两篇文章，相信能进一步加深理解。

2、关于作者

钱文品（老钱）：毕业于华中科技大学计算机科学与技术专业，互联网分布式高并发技术十年老兵，目前任掌阅科技资深后端工程师。熟练使用 Java、Python、Golang 等多种计算机语言，开发过游戏，制作过网站，写过消息推送系统和MySQL 中间件，实现过开源的 ORM 框架、Web 框架、RPC 框架等。

作者的Github： https://github.com/pyloque

3、系列文章

本文是系列文章中的第2篇，本系列大纲如下：

• 《脑残式网络编程入门(一)：跟着动画来学TCP三次握手和四次挥手》
• 《脑残式网络编程入门(二)：我们在读写Socket时，究竟在读写什么？》（本文）
• 《脑残式网络编程入门(三)：HTTP协议必知必会的一些知识》
• 《脑残式网络编程入门(四)：快速理解HTTP/2的服务器推送(Server Push)》
• 《脑残式网络编程入门(五)：每天都在用的Ping命令，它到底是什么？》
• 《脑残式网络编程入门(六)：什么是公网IP和内网IP？NAT转换又是什么鬼？》
• 《脑残式网络编程入门(七)：面视必备，史上最通俗计算机网络分层详解》
• 《脑残式网络编程入门(八)：你真的了解127.0.0.1和0.0.0.0的区别？》
• 《脑残式网络编程入门(九)：面试必考，史上最通俗大小端字节序详解》
  

4、Socket读写的简单过程理解

当客户端和服务器使用TCP协议进行通信时，客户端封装一个请求对象req，将请求对象req序列化成字节数组，然后通过套接字socket将字节数组发送到服务器，服务器通过套接字socket读取到字节数组，再反序列化成请求对象req，进行处理，处理完毕后，生成一个响应对应res，将响应对象res序列化成字节数组，然后通过套接字将字节数组发送给客户端，客户端通过套接字socket读取到字节数组，再反序列化成响应对象。



通信框架往往可以将序列化的过程隐藏起来，我们所看到的现象就是上图所示，请求对象req和响应对象res在客户端和服务器之间跑来跑去。

也许你觉得这个过程还是挺简单的，很好理解，但是实际上背后发生的一系列事件超出了你们中大多数人的想象。通信的真实过程要比上面的这张图复杂太多。你也许会问，我们需要了解的那么深入么，直接拿来用不就可以了么？

在互联网技术服务行业工作多年的经验告诉我，如果你对底层机制不了解，你就会不明白为什么对套接字socket的读写会出现各种奇奇乖乖的问题，为什么有时会阻塞，有时又不阻塞，有时候还报错，为什么会有粘包半包问题，NIO具体又是什么，它是什么特别新鲜的技术么？对于这些问题的理解都需要你了解底层机制。

5、Socket读写的细节过程分析

为了方便大家对通信底层的理解，我花了些时间做了下面这个动画，它并不能完全覆盖底层细节的全貌，但是对于理解套接字的工作机制已经足够了。请读者仔细观察这个动画，后面的讲解将围绕着这个动画展开。



我们平时用到的套接字其实只是一个引用(一个对象ID)，这个套接字对象实际上是放在操作系统内核中。这个套接字对象内部有两个重要的缓冲结构，一个是读缓冲(read buffer)，一个是写缓冲(write buffer)，它们都是有限大小的数组结构。

当我们对客户端的socket写入字节数组时(序列化后的请求消息对象req)，是将字节数组拷贝到内核区套接字对象的write buffer中，内核网络模块会有单独的线程负责不停地将write buffer的数据拷贝到网卡硬件，网卡硬件再将数据送到网线，经过一些列路由器交换机，最终送达服务器的网卡硬件中。

同样，服务器内核的网络模块也会有单独的线程不停地将收到的数据拷贝到套接字的read buffer中等待用户层来读取。最终服务器的用户进程通过socket引用的read方法将read buffer中的数据拷贝到用户程序内存中进行反序列化成请求对象进行处理。然后服务器将处理后的响应对象走一个相反的流程发送给客户端，这里就不再具体描述。

5.1细节过程：阻塞

我们注意到write buffer空间都是有限的，所以如果应用程序往套接字里写的太快，这个空间是会满的。一旦满了，写操作就会阻塞，直到这个空间有足够的位置腾出来。不过有了NIO(非阻塞IO)，写操作也可以不阻塞，能写多少是多少，通过返回值来确定到底写进去多少，那些没有写进去的内容用户程序会缓存起来，后续会继续重试写入。

同样我们也注意到read buffer的内容可能会是空的。这样套接字的读操作(一般是读一个定长的字节数组)也会阻塞，直到read buffer中有了足够的内容(填充满字节数组)才会返回。有了NIO，就可以有多少读多少，无须阻塞了。读不够的，后续会继续尝试读取。

5.2细节过程：ack

那上面这张图就展现了套接字的全部过程么？显然不是，数据的确认过程(ack)就完全没有展现。比如当写缓冲的内容拷贝到网卡后，是不会立即从写缓冲中将这些拷贝的内容移除的，而要等待对方的ack过来之后才会移除。如果网络状况不好，ack迟迟不过来，写缓冲很快就会满的。

5.3细节过程：包头

细心的同学可能注意到图中的消息req被拷贝到网卡的时候变成了大写的REQ，这是为什么呢？因为这两个东西已经不是完全一样的了。内核的网络模块会将缓冲区的消息进行分块传输，如果缓冲区的内容太大，是会被拆分成多个独立的小消息包的。并且还要在每个消息包上附加上一些额外的头信息，比如源网卡地址和目标网卡地址、消息的序号等信息，到了接收端需要对这些消息包进行重新排序组装去头后才会扔进读缓冲中。这些复杂的细节过程就非常难以在动画上予以呈现了。

5.4细节过程：速率

还有个问题那就是如果读缓冲满了怎么办，网卡收到了对方的消息要怎么处理？一般的做法就是丢弃掉不给对方ack，对方如果发现ack迟迟没有来，就会重发消息。那缓冲为什么会满？是因为消息接收方处理的慢而发送方生产的消息太快了，这时候tcp协议就会有个动态窗口调整算法来限制发送方的发送速率，使得收发效率趋于匹配。如果是udp协议的话，消息一丢那就彻底丢了。

网络协议内部实现还有更多复杂的细节有待继续挖掘，留着以后继续分析吧。

附录1：同类文章精选

如果您觉得本系列文章过于基础，您可直接阅读以下系列：

• 《网络编程懒人入门(一)：快速理解网络通信协议（上篇）》
• 《网络编程懒人入门(二)：快速理解网络通信协议（下篇）》
• 《网络编程懒人入门(三)：快速理解TCP协议一篇就够》
• 《网络编程懒人入门(四)：快速理解TCP和UDP的差异》
• 《网络编程懒人入门(五)：快速理解为什么说UDP有时比TCP更有优势》
• 《网络编程懒人入门(六)：史上最通俗的集线器、交换机、路由器功能原理入门》
• 《网络编程懒人入门(七)：深入浅出，全面理解HTTP协议》
  

《不为人知的网络编程》系列文章为高阶必读，该系列目录如下：

• 《不为人知的网络编程(一)：浅析TCP协议中的疑难杂症(上篇)》
• 《不为人知的网络编程(二)：浅析TCP协议中的疑难杂症(下篇)》
• 《不为人知的网络编程(三)：关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT》
• 《不为人知的网络编程(四)：深入研究分析TCP的异常关闭》
• 《不为人知的网络编程(五)：UDP的连接性和负载均衡》
• 《不为人知的网络编程(六)：深入地理解UDP协议并用好它》
• 《不为人知的网络编程(七)：如何让不可靠的UDP变的可靠？》
• 《不为人知的网络编程(八)：从数据传输层深度解密HTTP》
• 《不为人知的网络编程(九)：理论联系实际，全方位深入理解DNS》
  

关于移动端网络特性及优化手段的总结性文章请见：

• 《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
• 《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
• 《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
  

附录2：参考资料

《TCP/IP详解 - 第11章·UDP：用户数据报协议》
《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP连接的建立与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《通俗易懂-深入理解TCP协议（上）：理论基础》
《通俗易懂-深入理解TCP协议（下）：RTT、滑动窗口、拥塞处理》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《高性能网络编程(一)：单台服务器并发TCP连接数到底可以有多少》
《高性能网络编程(二)：上一个10年，著名的C10K并发连接问题》
《高性能网络编程(三)：下一个10年，是时候考虑C10M并发问题了》
《高性能网络编程(四)：从C10K到C10M高性能网络应用的理论探索》
《简述传输层协议TCP和UDP的区别》
《为什么QQ用的是UDP协议而不是TCP协议？》
《移动端即时通讯协议选择：UDP还是TCP？》
《技术往事：改变世界的TCP/IP协议（珍贵多图、手机慎点）》
《UDP中一个包的大小最大能多大？》
《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《NIO框架入门(一)：服务端基于Netty4的UDP双向通信Demo演示》
《NIO框架入门(二)：服务端基于MINA2的UDP双向通信Demo演示》
《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》
《P2P技术详解(一)：NAT详解——详细原理、P2P简介》
《P2P技术详解(二)：P2P中的NAT穿越(打洞)方案详解》
《P2P技术详解(三)：P2P技术之STUN、TURN、ICE详解》
《通俗易懂：快速理解P2P技术中的NAT穿透原理》
>> 更多同类文章 ……

每次读协议都觉得有收获

脑残一时爽，一直脑残一直爽

引用：zhangxiaojia 发表于 2019-09-07 11:11
写的很好，读了好几遍，过一段时间回来读都感觉有收获

写的很好，读了好几遍，过一段时间回来读都感觉有收获

引用：荒村野驴 发表于 2019-02-26 17:42
好好好，解开了我部分疑惑。
多谢大佬。
那个，文章开头有两个地方有错别字：字节数组写成了“自己数组” ...

多谢纠错，已经修订。

好好好，解开了我部分疑惑。
多谢大佬。
那个，文章开头有两个地方有错别字：字节数组写成了“自己数组”。

感谢博主分享！！！

引用：xzdfun 发表于 2018-07-21 17:12
这篇文章写得好，之前好多问题顿时迎刃而解！

这篇文章写得好，之前好多问题顿时迎刃而解！

大佬的讲解非常好，想问一下示例中的gif图，使用了什么工具制作的？包括图标和gif工具

写的非常好，意犹未尽