网络协议小故事（简述）

小故事

浏览器里面输入 https://www.kaola.com ，这是一个 URL。浏览器只知道名字是“www.kaola.com”，可是不知道具体的地点，因此不知道应该如何访问。因而，它打开地址簿去查找。可使用通常的地址簿协议 DNS 去查找，还可使用另外一种更加精准的地址簿查找协议 HTTPDNS。

不管用哪种方法查找，最终都会获得这个地址：106.114.138.24。这个是 IP 地址，是互联网世界的“门牌号”。

知道了目标地址，浏览器就开始打包它的请求。对于普通的浏览请求，每每会使用 HTTP 协议；可是对于购物的请求，每每须要进行加密传输，于是会使用 HTTPS 协议。不管是什么协议，里面都会写明“你要买什么和买多少”。

 

 

 

DNS、HTTP、HTTPS 所在的层咱们称为应用层。通过应用层封装后，浏览器会将应用层的包交给下一层去完成，经过 socket 编程来实现。下一层是传输层。传输层有两种协议，一种是无链接的协议 UDP，一种是面向链接的协议 TCP。对于支付来说，每每使用 TCP 协议。所谓的面向链接就是，TCP 会保证这个包可以到达目的地。若是不能到达，就会从新发送，直至到达。

TCP 协议里面会有两个端口，一个是浏览器监听的端口，一个是电商的服务器监听的端口。操做系统每每经过端口来判断，它获得的包应该给哪一个进程。

 

 

 

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

 

 

 

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

操做系统知道要离开本地去远方。虽然不知道远方在何处，可是能够这样类比一下：若是去国外要去海关，去外地就要去网关。而操做系统启动的时候，就会被 DHCP 协议配置 IP 地址，以及默认的网关的 IP 地址 192.168.1.1。

操做系统如何将 IP 地址发给网关呢？在本地通讯基本靠吼，因而操做系统大吼一声，谁是 192.168.1.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 的包，会像来的时候同样，通过千难万险到达你的我的电脑，最终进入浏览器，显示支付成功。