苦且绕不过去。经过多次放弃之后，我发现在我的职业生涯中，网络这一关无论如何也绕不过去。本来觉得写Java程序时可以依赖别人的库，所以就不用关心这么多底层的技术了，但是到后来才发现，服务数量一多，吞吐量一大，我们关心的不再仅仅是某个Java应用，而是要提升整个集群的性能，这时网络问题就会出现。而且大规模的微服务架构必定要上云、使用VPC网络，这时就必定要考虑双活和灾备，必定要做各个层次的负载均衡，这些都需要网络方面的技术。既然绕不过去，那就必须“啃”下它，于是我就进入了暗无天日的网络协议学习的过程。
见山开路、遇水搭桥，遇到一个知识点攻克一个，再将其写到博客或者笔记里面。有时候要看很多文章和书才能攻克一个知识点，但我还是每天下班抱着网络技术相关的文章和书看，直到将各个零散的知识点串连了起来。后来在定位网络问题的时候，我开始有了自己的思路，这时才感觉算是暂时趟过了这条河。
网络协议知识点太多，学完记不住。大部分读者应该都学过计算机网络课程，学的时候感觉并不难，尤其这门课没有公式，更像是文科的东西。学了一大堆东西，也背了一大堆东西，但是最终应付完考试之后，都“还给了老师”
每次都感觉自己好像学会了，但实际应用的时候依旧无从下手。虽然很多细节都摸索得差不多了，但是当自己去应用和调试时，才发现还是没有任何思路。比如，当创建出来的虚拟机不能上网时，还是无从下手，学过的很多东西，似乎都用不上。我把这种现象总结为：一看觉得懂，一问就打鼓，一用就糊涂。
所以本书使用了“趣谈”这种方式，它可以解决从“入门到放弃”的问题，把晦涩的知识点和一些有趣的故事通过比喻的方式结合起来，这样更容易帮助读者系统、深入地了解网络技术的知识点和大致的工作流程。
主要包括的内容和总结三部分给大家进行网络协议的拓展学习，希望大家能够喜欢！！
第1 章 通信协议概述
1.1 为什么要学习网络协议
相信大家都信过通天塔的故事，上帝为了阻止人类联合起来，让人类说不同的语言，人类没法沟通，达不成“协议", 通天塔的计划就失败了。
但是千年以后，有一种叫“程序猿”的物种，“敲”着一种这个群体通用的语言，打造着互联网世界的“通天塔”。如今的世界，正是因为互联网，才连接在一起。
如果你是程序员，一定看得懂上面这一段文字。这是每一个程序员向计算机世界说“你好，世界”的方式。但是，你不一定知道，这段文字也是一种协议，是人类和计算机沟通的协议，只有通过这种协议，计算机才知道我们想让它做什么。
第 2 章 从二层到三层
2.1 从物理层到MAC 层：如何在宿舍里自己组网玩联机游戏
第一层：物理层
路由器的使用发生在第三层上。我们先从第一层物理层开始说。
物理层能折腾什么？现在的同学可能想不到，我们当时去学校配电脑的地方买网线，卖网线的师傅都会问，你的网线是要电脑连电脑啊，还是电脑连网口啊？
我们要的是电脑连电脑的网线。就是将一根网线的一头插在一台电脑的网卡上，另一头插在另一台电脑的网卡上。但是在当时，用普通的网线这样连接是通不了的，所以水晶头要做交叉线，用的就是所谓的1-3,2-6交叉接法。
水晶头的第l、2脚和第3'6脚，分别起着WL发信号的作用。将一端的1号线和3号线、2号线和6号线互换一下位置，就能够在物理层实现两端通信。
当然电脑连电脑，除了网线要交叉，还需要配置这两台电脑的IP地址、子网掩码和默认网关。这3个概念前文已经详细描述过了。要想两台电脑能够通信，两台电脑的这3项必须属于一个网络，否则是行不通的。
第二层：MAC层
你可能已经发现问题了。Hub采取的是广播的模式，如果每一台电脑发出的网络包，宿舍里的每台电脑都能收到，那就麻烦了。这时就需要解决以下几个问题：
这个网络包是发给谁的？谁应该接受？
大家都在发，会不会产生混乱？有没有谁先发、谁后发的规则？
如果发送的时候出现了错误，怎么办
这几个问题，都发生在第二层链路层，即MAC层要解决的问题。MAC的全称是MediumAccess Control，即媒体访问控制。控制什么呢？其实就是给媒体发送数据时，控制谁先发、谁后发，防止发生混乱。MAC层解决的是第二个问题，这个问题学名叫多路访问。有很多算法可以解决。就像车管所管理车辆一样，会想出很多办法，比如以下3种方式。
方式一：分多个车道。每个车一个车道，你走你的，我走我的。这在计算机网络里叫作信道划分协议。
方式二：今天单号出行，明天双号出行，轮着来。这在计算机网络里叫作轮流协议。
方式三：不管三七二十一，有事儿先出门，发现特堵，就回去，错过高峰再出门。这在计算机网络里叫作随机接入协议。著名的以太网，用的就是这个协议。
第 3 章 重要的传输层
3.1 UDP：虽然简单但是可以走制化
TCP和UDP有哪些区别
一般在面试时，如果面试官问这两个协议的区别是什么，大部分面试者会回答，TCP是面向连接的，UDP是面向无连接的。
什么叫面向无连接，什么叫面向无连接呢？在互通之前，面向连接的协议会先建立连接。例如，TCP会进行三次握手来建立连接，而UDP不会。为什么要建立连接呢？TCP可以进行三次握手，UDP可以发三个包，难道不都是建立连接吗？
所谓的建立连接，是为了维护客户端和服务端的连接而去建立一定的数据结构，从而维护双方交互的状态，并用这样的数据结构来保证面向连接的特性。
例如，TCP提供可靠交付。通过TCP连接传输的数据能够无差错、不丢失、不重复，并且可以按序到达。我们都知道IP包是没有提供任何可靠性保证的，一旦发出去，就像西天取经，走丢了、被妖怪吃了，都只能随它去。TCP号称能做到连接维护程序做的事情，这部分内容在下面两节中会详细描述。而UDP继承了IP包的特性，不保证传输的数据不丢失，也不保证按序到达。
再如，TCP是面向字节流的，发送时发的是一个流，没头没尾。但TCP基于的E层发送的可不是一个流，而是一个个的IP包。到TCP层后之所以变成流，是因为TCP自身的状态维护做了相应的处理。而UDP则不一样，它继承了IP包的特性，也是一个一个地发，一个一个地收。在UDP层发送的一个个数据包，还有－个名字叫数据包。
另外，TCP是可以进行拥塞控制的。它意识到包已经被丢弃或者网络环境变差时，就会根据情况调整自己的行为，看看是不是数据包发得太快了，要不要发慢点。UDP就不会，应用让我发，我就发，管它洪水滔天。
因而TCP是有状态服务，通俗地讲就是它“有脑子”，它精确地知道数据包是否已经被发送出去、是否被接收、发送到哪儿了、应该接收哪个数据包了，错一点儿都不行。而UDP则是无状态服务，通俗地说就是它“没脑子”，天真无邪，发出去就发出去了，后续就不管了。
如果说MAC层定义了本地局域网的传输行为，IP层定义了整个网络端到端的传输行为，那么这两层就基本定义了这样的“基因”：网络传输是以包为单位的（网络包在不同的层有不同的叫法，链路层叫帧，网络层叫包，传输层叫段，我们可以笼统地称之为包），包单独传输，自行选路，在不同的设备上进行封装、解封装，不保证到达。基于这个“基因”，生下来的“孩子”UDP就完全继承了这些特性，几乎没有自己的思想。
第 4 章 常用的应用层
4.1 HTTP：看个新闻原来这么麻烦
接下来开始讲应用层的协议。就从最常用的HTTP开始讲起。
HTTP几乎是每个人上网用的第一个协议，同时也是很容易被忽略的协议。
既然本节要讲看新闻，咱们就先登录某新闻网站http://www.***·com。
http//www.***.com是一个URL( Uniform Resource Locator，统一资源、定位符）。之所以叫统一，是因为它是有格式的。HTTP称为协议，WWW.＊忡.com是一个域名，表示互联网上的一个位置。有的URL会有更详细的位置标识，例如http://www.***·corn/index.html。正是因为URL是统一的，所以当你把这样一个字符串输入到浏览器的地址框里进行搜索的时候，浏览器才能知道如何进行统一处理。
第 5 章 陌生的数据中心
5.1 DNS：网络世界的地址簿
什么是DNS服务器
在网络世界，也是一样的。你肯定记得住网站的名称，但是很难记住网站的IP地址，因此也需要一个地址簿，即DNS(Domain Name System，域名系统）服务器。
由此可见，DNS服务器在日常生活中多么重要。每个人上网都需要访问它。但是同时，这对它来讲也是非常大的挑战。一旦它出了故障，整个互联网都将瘫痪。另外，上网的人分布在世界各地，如果大家都去同一个地方访问某个服务器，时延将会非常大。因而，DNS服务器一定要设置成高可用、高并发和分布式的。
于是，就有了树状的层次结构，如图所示。
根DNS服务器：返回顶级域DNS服务器的IP地址。
顶级DNS服务器：返回权威DNS服务器的IP地址。
权威DNS服务器：返回相应主机的E地址。
第 6 章 云计算中的网络
6.1 云中网络：自己拿地成本高，购买公寓更灵活
我们知道了数据中心里面堆着一大片一大片的机器，相互之间用网络连接。如果机器数量非常多，那么维护起来还是挺麻烦的，有好多不灵活的地方，比如以下几点
采购不灵活：如果客户需要一台电脑，那就需要自己采购、上架、插网线、安装操作系统，周期非常长。一旦采购了，一用就得好多年，不能退货，｜哪怕业务不做了，机器还在数据中心里留着。
运维不灵活：一旦需要扩容CPU、内存、硬盘，都需要去机房手动弄，非常麻烦。
规格不灵活：采购的机器往往动不动几百GB的内存，而每个应用往往可能只需要4核8GB，所以很多应用混合部署在上面，端口可能会相互冲突，容易相互影响。
复用不灵活：一台机器，一旦一个用户不用了，另外一个用户，就需要重装操作系统。
因为原来的操作系统可能遗留着很多数据，非常麻烦。
第 7 章 容器技术中的网络
7.1 容器网络：来去自由的日子，不买公寓去合租
如果说虚拟机是买公寓，容器则相当于合租，有一定的隔离，但是隔离性没有那么好。云计算解决了基础资源层的弹性伸缩问题，却没有解决由于基础资源层弹性伸缩而带来的PaaS层应用批量、快速部署问题。于是，容器应运而生。
容器即Container，而Container的另一个意思是集装箱。其实容器的思想就是要变成软件交付的集装箱。集装箱有两个特点：一是打包，二是标准。
在没有集装箱的时代，假设要将货物从A运到B，中间要经过三个码头、换三次船。那么每次都要将货物卸下船来，弄得乱七八糟，然后再搬上船重新摆好，如图7-1所示。在没有集装箱的时候，每次换船，船员们都要在岸上待几天才能干完活。
有了尺寸全部都一样的集装箱以后，可以把所有的货物都打包在一起，每次换船的时候，把整个集装箱搬过去就行了，几个小时就能完成，船员换船时间大大缩短，如图7-2所示。这是集装箱的“打包”和“标准”两大特点在生活中的应用。
第 8 章 微服务相关协议
8.1 基于XML 的SOAP：不要说NBA，请说美国职业篮球联赛
ONC RPC存在哪些问题
ONCRPC将客户端要发送的参数及服务端要发送的回复都压缩为一个二进制串，这样固然能够解决双方协议约定的问题，但是仍然不方便。
首先，需要双方的压缩格式完全一致，一点都不能差。一旦有少许的差错，多一位、少一位或者错一位，都可能造成无法解压缩。当然，我们可以通过提高传输层的可靠性，以及加入校验值等方式来减少传输过程中的差错。
其次，协议修改不灵活。除了传输过程中造成的差错，客户端因为业务逻辑的改变添加或者删除了字段，或者服务端添加或者删除了语段而没有及时通知对方，或者线上系统没有及时升级，都会造成解压缩不成功。
因而，当业务发生改变，需要多传输或者少传输一些参数时，都需要及时通知对方，并且根据约定好的协议文件重新生成双方的Stub程序。自然，这样操作的灵活性比较差。
如果仅仅是沟通的问题还好解决，更难处理的是版本的问题。比如在服务端提供一个服务，参数的格式是版本l的，已经有50个客户端在线上调用了。现在有一个客户端有一个需求，要加一个字段，怎么办呢？这可是一个大工程，所有的客户端都要适配这个，重新写程序，哪怕不需要这个字段的客户端也要加上这个字段，并传输0，这些程序员就很委屈，本来没我什么事儿，为什么让我也忙活？
最后，ONCRPC的设计明显是面向函数的，而非面向对象。而当前面向对象的业务逻辑设计与实现方式已经成为主流。
这一切的根源就在于压缩。就像平时我们爱用缩略语。如果是篮球爱好者，你直接说NBA(National Basketball Association，美国职业篮球联赛），他马上就知道什么意思，但是如果你和一个大妈说NBA，她可能就听不懂。
所以，这种RPC框架只能用于客户端和服务端全由一批人开发的场景，或者至少客户端和服务端的开发人员要密切沟通，相互合作，有大量的共同语言，才能按照既定的协议顺畅地进行工作。
XML与SOAP
但是，一般情况下，我们做一个服务，都是要提供给陌生人用的，你和客户不会经常沟通，也没有什么共同语言。这时就不适合用缩略语，就像你给别人介绍阳A，你要说美国职业篮球联赛，这样不管他是做什么的，都能听得懂。
放到我们的场景中，就是用文本类的方式进行传输。无论哪个客户端获得这个文本，都能够知道它的意义。
第 9 章 网络协议知识串讲
9.1 知识串讲:用"双*"的故事串起网络协议的碎片知识(上)
9.2 知识串讲:用"双*"的故事串起网络协议的碎片知识(中)
9.3 知识串讲:用"双*“的故事串起网络协议的碎片知识（下)
9.4 搭建—个网络实验环境:授人以鱼不如授人以渔
总目录：
好了，本篇文章就分享到这里了，希望这份【趣谈网络协议】对大家有所帮助，小编在这里也感谢大家对小编的支持