写在前面
2018年6月20日拿到毕业证，正式结束了自己的学生生涯。
2018年7月2日，自己正式开始了人生中的第一份正式工作，人人车的Android开发工程师。
2018年7月13日，决定要好好督促自己学一学习，所以就打算再一次刚起公众号之路。逼迫自己有计划的去学习，有计划的去输出。因为最近碰巧赶上了需求大爆发时期，所以这段时间的学习计划，以不需要大量时间投入的计算机基础知识为主，重在修炼自己的内功。前段时间买了一个计算机网络的课程，所以近期打算记录一下这方面的知识。
笔记正文
这里是一个关于计算机网络的系列文章，主要是自己对一个收费课程的学习记录。这里就不放课程链接了，如果对课程感兴趣的话，可以后台私聊我。
以下内容和图片由我整理自《极客时间》付费内容，如有侵权，告知即删。
HTTP协议相关
当我们在浏览器里面输入https://www.kaola.com时，毫无疑问这是一个URL。不过浏览器只知道这个链接的名字是https://www.kaola.com ，但此外不知道任何其他有用的信息，所以接下来的第一步，浏览器打开地址簿去查找这个链接背后的IP地址。一般可以使用的地址薄协议是DNS，还可以使用另一种更加精准的地址簿查找协议HTTPDNS 。
无论用哪一种方法查找，最终都会得到这个地址：106.114.138.24 。这个是网易考拉的服务器IP地址，是互联网世界的“门牌号”。知道了目标地址，浏览器就开始打包它的请求。现在我们普遍会使用HTTPS协议。当然无论是什么协议，里面都会写明这次请求所需要携带的信息，比如作为一名剁手党，你所要携带的信息是“要买什么和买多少”。
TCP协议相关
DNS、HTTP、HTTPS所在的层我们称为应用层。经过应用层封装后，浏览器会将应用层的包交给下一层去完成，通过socket编程来实现。下一层是传输层。传输层有两种协议，一种是无连接的协议UDP， 一种是面向连接的协议TCP。对于支付来讲，往往使用TCP协议。所谓的面向连接就是，TCP会保证这个包能够到达目的地。如果不能到达，就会重新发送，直至到达。
TCP协议里面会有两个端口，一个是浏览器监听的端口，一个是电商的服务器所监听的端口。操作系统往往通过端口来判断，它得到的包应该给哪个进程。
获取IP地址
传输层封装完毕后，浏览器会将包交给操作系统的网络层。网络层的协议是IP协议。在IP协议里面会有源IP地址，即浏览器所在机器的IP地址和目标IP地址，也即电商网站所在服务器的IP地址。（也就是我们上文通过DNS协议获取到的IP地址）
获取MAC地址
操作系统既然知道了目标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 的包，，会像来的时候一样，经过千难万险到达你的个人电脑，最终进入浏览器，显示支付成功。
笔记小结
为什么有了IP，还要有mac地址
1.局域网内IP地址是动态分配的，假如我是192.168.2.100，如果我下线了，可能IP就分配给了另一台电脑。IP和设备并不总是对应的，这对通信就产生了问题，但是MAC地址不同，MAC地址和设备是一一对应且全球唯一的。所以局域网使用MAC地址通信没有问题。
2.历史遗留问题：早期的以太网只有交换机，没有路由器，以太网内通过MAC地址通信。后来才有了互联网，为了兼容原本的模式，采用了IP+MAC地址通信的方式。为啥不推到了重来呢？看看IPv6的处境你就知道了。所以是先有MAC地址后有的IP，IP的提出主要还是因为MAC地址本身的缺陷，这个问题换成有了MAC为何还要IP地址也很有意思。
3.MAC地址本身的缺陷：因为MAC地址是硬件提供商写在网卡中的，MAC地址虽然唯一但是不能表明用户在整个互联网中的位置，除非维护一个超级大MAC地址对应表，那寻址效率肯定爆炸。但是IP地址解决了这个问题，因为IP地址是网络提供商给你的，所以你在哪里整个网络都是知道的。
网卡MAC码是由全球惟一的一个固定组织来分配的，未经认证和授权的厂家无权生产网卡。每块网卡都有一个固定的卡号，并且任何正规厂家生产的网卡上都直接标明了卡号，一般为一组12位的16进制数。其中前6位代表网卡的生产厂商。后面的位数是设备号。
尾声
这是这些天我对《计算机网络》学习的一次笔记。大部分内容是基于前辈们总结，我又记录了一遍。算是对自己学习结果的一次确认吧，希望可以对各位看官有些帮助。
本菜开源的一个自己写的Demo，这个项目拆解并组合了很多业务。目的在于遇到类似业务，可以快速的ctrl+c/v。希望能给Androider们有所帮助，水平有限，见谅见谅…
https://github.com/zhiaixinyang/PersonalCollect
这是一个主推面试踩坑的公众号！
因为身边的同学从事互联网相关职业的比较多，并且大家闲时聊天时总会吐槽找工作有很多坑，所以打算把身边同学找工作的经验，统统收集起来。提供给想从事这方面同学，希望圈内好友可以共同进步，共同少踩坑。
