这是我向网易大神刘超学习网络协议的第一篇笔记。

一年一度的618即将来临，我已磨刀刀霍霍，准备向天猫贡献我的双手。巴拉巴拉。。。好了，直接进入主题，618与网络协议有什么关系呢？我们在浏览器里输入,这是一个URL。浏览器将呈现一个色彩缤纷的天猫世界。其实浏览器只知道名字是‘www.tmall.com',但是不知道具体的地点，所以不知道应该如何访问。于是，它打开地址簿去查找。可以使用一般的地址簿协议DNS去查找，还可以使用另一种更加精准的地址簿查找协议HTTPDNS。

无论用哪一种方式查找，最终都会得到这个地址：117.41.238.241（通过ping+域名查询）。这个是IP地址，是互联网世界的“门牌号”。

知道了目标地址，浏览器就开始打包它的请求。对于普通的浏览请求，往往会使用HTTP协议；但是对于购物的请求，往往需要进行加密传输，因而会使用HTTPS协议。无论是什么协议，里面都会写明你要干什么（比如我点击下单，那就会写上你要买什么和买多少）。


DNS、HTTP、HTTPS所在的层我们称之为应用层。经过应用层封装后，浏览器会将应用层的包交给下一层去完成，通过socket编程来实现。下一层是传输层。传输层有两种协议，一种是无连接的协议UDP，一种是面向连接的TCP协议。对于支付来讲，往往使用TCP协议。所谓的面向连接就是，TCP会保证这个包能够到达目的地。如果不能到达，就会重新发送，直至到达（这是一个信守承若的好孩子）。

TCP协议里面会有两个端口，一个是浏览器监听端口，一个是电商的服务器监听端口。操作系统往往通过端口来判断，它得到的包应该给哪个进程。（HTTP默认是80，HTTPS默认是443）


传输层封装完毕后，浏览器会将包交给操作系统的网络层。网络层的协议是IP协议。在IP协议里面会有源IP地址（通过ipconfig可查询），即浏览器所在的IP地址和目标IP地址，也即电商网站所在服务器的IP地址。


操作系统既然知道了目标IP地址，就开始想如何根据这个门牌号找到目标机器。操作系统往往会判断，这个目标IP地址是本地人，还是外地人。如果是本地人，从门牌号就能看出来，但是显然电商网站不在本地，而在遥远的地方。

操作系统知道要离开本地去远方。虽然不知道远方在哪，但是可以这样类比一下：如果我们人去国外要去海关，那在网络世界里去外地就要去网关。而操作系统启动的时候，就会被DHCP协议配置IP地址，以及默认的网关的IP地址192.168.0.1（本人电脑默认网关）。

操作系统如何将IP地址发给网关呢？在本地通信基本靠吼，于是操作系统大吼一声，谁是192.168.0.1啊？网关会回答它，我就是，我的本地地址在村东头。这个本地地址就是MAC地址，而大吼那一声是ARP协议。


于是操作系统将IP包交给了下一层，也就是MAC层。网卡再将包发出去。由于这个包里是有MAC地址的，因而它能够到达网关。

网关收到包之后，会根据自己的知识，判断下一步应该怎么走。网关往往是一个路由器，到某个IP地址应该怎么走，这个叫做路由表。

路由器有点像玄奘西行路过的一个个国家的一个个城关。每个城关都连着两个国家，每个国家相当于一个局域网，在每个国家内部，都可以使用本地的地址MAC进行通信。

一旦跨越城关，就需要拿出IP头来（过关文牒），里面写着“贫僧来自东土大唐（就是源IP地址），欲往西天拜佛求经（指的是目标IP地址）。路过宝地，借宿一宿，明日启行，请问接下来该怎么走啊？”


城关往往知道这些“知识”的，因为成功和临近城关也会经常沟通。到哪里应该怎么走，这种沟通的协议称为路由协议，常用的有OSPF和BGP。


城关与城关之间是一个国家，当网络包知道了下一步去哪个城关，还是要使用国家内部的MAC地址，通过下一个城关的MAC地址，找到下一个城关，然后再问下一步的路怎么走，一直走出最后一个城关。

最后一个城关知道这个网络包要去的地方。于是，对着这个国家吼一声，谁是目标IP啊？目标服务器就会回复一个MAC地址。网络包过关后，通过这个MAC地址就能找到目标服务器。

目标服务器发现MAC地址对上后，取下MAC头，发给操作系统的网络层。发现IP也对上了，就取下IP头。IP头里会写上一层封装的TCP协议，然后将其交给传输层，即TCP层。

在这一层里，对于收到的每一包，都会有一个回复的包说明收到了。这个回复的包绝非这次下单请求的结果，例如购物是否成功啊，扣了多少钱啊...而仅仅是TCP层的一个说明，即收到之后的回复。当然这个回复，会沿着刚才来的方向走回去，报个平安。

如果过一段时间还是没到，发送端的TCP层就会重新发送这个包，还是上面的过程，直到有一天收到平安到达的回复。这个重试绝非你浏览器重新将下单这个动作重新请求一次。对于浏览器来讲，就发送了一次下单请求，TCP层不断自己闷头重试。除非TCP这一层出了问题，例如连接断了，才轮到浏览器的应用层重新发送下单请求。

当网络包平安到达 TCP 层之后，TCP 头中有目标端口号，通过这个端口号，可以找到电商网站的进程正在监听这个端口号，假设一个 Tomcat，将这个包发给电商网站。


电商网站的进程得到 HTTP 请求的内容，知道了要买东西，买多少。往往一个电商网站最初接待请求的这个 Tomcat 只是个接待员，负责统筹处理这个请求，而不是所有的事情都自己做。例如，这个接待员要告诉专门管理订单的进程，登记要买某个商品，买多少，要告诉管理库存的进程，库存要减少多少，要告诉支付的进程，应该付多少钱，等等。  

如何告诉相关的进程呢？往往通过 RPC 调用，即远程过程调用的方式来实现。远程过程调用就是当告诉管理订单进程的时候，接待员不用关心中间的网络互连问题，会由 RPC 框架统一处理。RPC 框架有很多种，有基于 HTTP 协议放在 HTTP 的报文里面的，有直接封装在 TCP 报文里面的。  

当接待员发现相应的部门都处理完毕，就回复一个 HTTPS 的包，告知下单成功。这个 HTTPS 的包，会像来的时候一样，经过千难万险到达你的个人电脑，最终进入浏览器，显示支付成功。