计网相关


阅读数: 次   

IP协议相关技术

​ DNS 域名解析

​ ARP 与 RARP 协议

​ DHCP 动态获取 IP 地址

​ NAT 网络地址转换

​ ICMP 互联网控制报文协议

​ IGMP 因特网组管理协

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
1. DNS 域名解析(以将域名网址自动转换为具体的 IP 地址)
	域名的层级关系类似一个树状结构：e.g  www.server.com
	根 DNS 服务器
	顶级域 DNS 服务器（com）
	权威 DNS 服务器（server.com）

2.ARP 与 RARP 协议
	ARP协议(求得下一跳的MAC地址借助ARP请求与ARP响应两种类型的包确定MAC地址 IP地址-》MAC地址)
	主机会通过广播发送 ARP 请求，这个包中包含了想要知道的 MAC 地址的主机 IP 地址。
	当同个链路中的所有设备收到 ARP 请求时，会去拆开 ARP 请求包里的内容，如果 ARP 请求包中
	的目标 IP 地址与自己的 IP 地址一致，那么这个设备就将自己的 MAC 地址塞入 ARP 响应包返回
	给主机。
	操作系统通常会把第一次通过 ARP 获取的 MAC 地址缓存起来，以便下次直接从缓存中找到对应 IP 地
	址的 MAC 地址。
	不过，MAC 地址的缓存是有一定期限的，超过这个期限，缓存的内容将被清除。
	
	RARP协议(MAC地址-》IP地址)
	ARP 协议是已知 IP 地址求 MAC 地址，那 RARP 协议正好相反，它是已知 MAC 地址求 IP 地址。例如
	将打印机服务器等小型嵌入式设备接入到网络时就经常会用得到。
	通常这需要架设一台 RARP 服务器，在这个服务器上注册设备的 MAC 地址及其 IP 地址。然后再将
	这个设备接入到网络，接着：
	该设备会发送一条「我的 MAC 地址是XXXX，请告诉我，我的IP地址应该是什么」的请求信息。
	RARP 服务器接到这个消息后返回「MAC地址为 XXXX 的设备，IP地址为 XXXX」的信息给这个
	设备。
	最后，设备就根据从 RARP 服务器所收到的应答信息设置自己的 IP 地址。
	
3.DHCP(DHCP 在生活中我们是很常见的了，我们的电脑通常都是通过四个步骤DHCP动态获取IP地址，大大省去了配
IP信息繁琐的过程。)
	1.客户端首先发起 DHCP 发现报文（DHCP DISCOVER） 的 IP 数据报，由于客户端没有 IP 地
    址，也不知道 DHCP 服务器的地址，所以使用的是 UDP 广播通信，其使用的广播目的地址是
    255.255.255.255（端口 67） 并且使用 0.0.0.0（端口 68） 作为源 IP 地址。DHCP 客户端将该
    IP 数据报传递给链路层，链路层然后将帧广播到所有的网络中设备。
    
    2.DHCP 服务器收到 DHCP 发现报文时，用 DHCP 提供报文（DHCP OFFER） 向客户端做出响
    应。该报文仍然使用 IP 广播地址 255.255.255.255，该报文信息携带服务器提供可租约的 IP 地
    址、子网掩码、默认网关、DNS 服务器以及 IP 地址租用期。
    
    3.客户端收到一个或多个服务器的 DHCP 提供报文后，从中选择一个服务器，并向选中的服务器发
    送 DHCP 请求报文（DHCP REQUEST进行响应，回显配置的参数。
    
    4.最后，服务端用 DHCP ACK 报文对 DHCP 请求报文进行响应，应答所要求的参数。
    
    如果租约的 DHCP IP 地址快期后，客户端会向服务器发送 DHCP 请求报文：
    服务器如果同意继续租用，则用 DHCP ACK 报文进行应答，客户端就会延长租期。
    服务器如果不同意继续租用，则用 DHCP NACK 报文，客户端就要停止使用租约的 IP 地址。
    可以发现，DHCP 交互中，全程都是使用 UDP 广播通信。 咦，用的是广播，那如果 DHCP 服务器和客户端不是在同		一个局域网内，路由器又不会转发广播包，那不是 每个网络都要配一个 DHCP 服务器？
    所以，为了解决这一问题，就出现了 DHCP 中继代理。有了 DHCP 中继代理以后，对不同网段的 IP 地
    址分配也可以由一个 DHCP 服务器统一进行管理。
   
5.NAT(一种网络地址转换NAT的方法(是同个公司、家庭、教室内的主机对外部通信时，把私有 IP 地址转换成公有 IP 地
址。以此再次缓解了IPv4地址耗尽的问题) 网络地址与端口转换 NAPT
	正确地转换地址跟端口(/地址)的组合的NAPT(/NAT)转换表在NApT路由器上自动生成。例如，在 TCP 的情况下，建	 立TCP连接首次握手时的SYN包
    一经发出，就会生成这个表。而后又随着收到关闭连接时发出 FIN 包的确认应答从表中被删除。
    NAT 那么牛逼，难道就没缺点了吗？当然有缺陷，肯定没有十全十美的方案。
    由于 NAT/NAPT 都依赖于自己的转换表，因此会有以下的问题：
    外部无法主动与 NAT 内部服务器建立连接，因为 NAPT 转换表没有转换记录。
    转换表的生成与转换操作都会产生性能开销。
    通信过程中，如果 NAT 路由器重启了，所有的 TCP 连接都将被重置。
    如何解决 NAT 潜在的问题呢？
    解决的方法主要有两种方法。
    第一种就是改用 IPv6
    IPv6 可用范围非常大，以至于每台设备都可以配置一个公有 IP 地址，就不搞那么多花里胡哨的地址转
    换了，但是 IPv6 普及速度还需要一些时间。
    第二种 NAT 穿透技术（内网穿透技术）
    NAT 穿越技术拥有这样的功能，它能够让网络应用程序主动发现自己位于 NAT 设备之后，并且会主动
    获得 NAT 设备的公有 IP，并为自己建立端口映射条目，注意这些都是 NAT设备后的应用程序自动完成
    的。
    也就是说，在 NAT 穿透技术中，NAT设备后的应用程序处于主动地位，它已经明确地知道 NAT 设备要
    修改它外发的数据包，于是它主动配合 NAT 设备的操作，主动地建立好映射，这样就不像以前由 NAT
    设备来建立映射了。
    说人话，就是客户端主动从 NAT 设备获取公有 IP 地址，然后自己建立端口映射条目，然后用这个条目
    对外通信，就不需要 NAT 设备来进行转换了。
    
6.ICMP：互联网控制报文协议(确认IP包是否成功送达目标地址、报告发送过程中IP包被废弃的原因和改善网络设置等。)
	ICMP报文是封装在IP包里面，它工作在网络层，是IP协议的助手。
	ICMP 大致可以分为两大类：
	一类是用于诊断的查询消息，也就是「查询报文类型」
	另一类是通知出错原因的错误消息，也就是「差错报文类型」
	
7.IGMP：因特网组管理协(和ICMP无任何关系) ，工作在主机（组播成员）和最后一跳路由之间
	在前面我们知道了组播地址，也就是D类地址，既然是组播，那就说明是只有一组的主机能收到数据
	包，不在一组的主机不能收到数组包，怎么管理是否是在一组呢？那么，就需要IGMP协议了。
	
	IGMP 报文向路由器申请加入和退出组播组，默认情况下路由器是不会转发组播包到连接中的主
    机，除非主机通过IGMP加入到组播组，主机申请加入到组播组时，路由器就会记录 IGMP 路由
    器表，路由器后续就会转发组播包到对应的主机了。
    IGMP报文采用IP封装，IP头部的协议号为2，而且TTL字段值通常为 1，因为IGMP是工作在
    主机与连接的路由器之间。
1
2
3
4
5
6
常见问题：
	假设一台机器加入组播地址，需要把IP改成组播地址吗？如果离开某个组播地址，需要dhcp重新请求个IP吗？
	组播地址不是用于机器 ip 地址的，因为组播地址没有网络号和主机号，所以跟 dhcp 没关系。组播地址
    一般是用于 udp 协议，机器发送 UDP 组播数据时，目标地址填的是组播地址，那么在组播组内的机器
    都能收到数据包。
    是否加入组播组和离开组播组，是由 socket 一个接口实现的，主机 ip 是不用改变的

ping的工作原理：ping是基于ICMP协议工作的，所以需要先熟悉ICMP协议

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
ICMP包头的类型字段，大致可以分为两大类： 
	一类是用于诊断的查询消息，也就是「查询报文类型」 
	另一类是通知出错原因的错误消息，也就是「差错报文类型」
	
    查询报文类型 回送消息 —— 类型 0 和 8
    回送消息(请求8与响应0)用于进行通信的主机或路由器之间，判断所发送的数据包是否已经成功到达对端的一种消
    息， ping命令就是利用这个消息实现的。
    
    差错报文类型
    IP 路由器无法将 IP 数据包发送给目标地址时，会给发送端主机返回一个目标不可达的 ICMP 消息，并
    在这个消息中显示不可达的具体原因，原因记录在 ICMP 包头的代码字段。
    由此，根据 ICMP 不可达的具体消息，发送端主机也就可以了解此次发送不可达的具体原因。
    接下来，说明几个常用的 ICMP 差错报文的例子：
    目标不可达消息 —— 类型 为 3
    	代码号：0  网络不可达
    	代码号：1 主机不可达
    	代码号：2 协议不可达
    	代码号：3 端口不可达
    	代码号：4 需要进行分片但设置不了分片
    原点抑制消息 —— 类型 4
    	在使用低速广域线路的情况下，连接 WAN 的路由器可能会遇到网络拥堵的问题。
        ICMP原点抑制消息的目的就是为了缓和这种拥堵情况。
        当路由器向低速线路发送数据时，其发送队列的缓存变为零而无法发送出去时，可以向 IP 包的源地址
        发送一个ICMP原点抑制消息。
        收到这个消息的主机借此了解在整个线路的某一处发生了拥堵的情况，从而增大 IP 包的传输间隔，减
        少网络拥堵的情况。
        然而，由于这种 ICMP 可能会引起不公平的网络通信，一般不被使用。
    重定向消息 —— 类型 5
    	如果路由器发现发送端主机使用了「不是最优」的路径发送数据，那么它会返回一个 ICMP 重定向消息
		给这个主机。在这个消息中包含了最合适的路由信息和源数据。这主要发生在路由器持有更好的路由信息的情况		下。路由器会通过这样的 ICMP 消息告知发送端，让它下次发给另外一个路由器。
    超时消息 —— 类型 11 
        IP 包中有一个字段叫做 TTL （ Time To Live ，生存周期），它的值随着每经过一次路由器就会减
        1，直到减到 0 时该 IP 包会被丢弃。此时，路由器将会发送一个 ICMP 超时消息给发送端主机，并通知该包已		被丢弃。设置IP包生存周期的主要目的，是为了在路由控制遇到问题发生循环状况时，避免 IP 包无休止地在网		络上被转发

	ping ————查询报文类型的使用
    同个子网下的主机 A 和 主机 B，主机 A 执行 ping 主机 B 后，我们来看看其间发送了什么？
    ping 命令执行的时候，源主机首先会构建一个 ICMP 回送请求消息数据包。
    ICMP 数据包内包含多个字段，最重要的是两个：
    第一个是类型，对于回送请求消息而言该字段为 8 ；
    另外一个是序号，主要用于区分连续 ping 的时候发出的多个数据包。
    每发出一个请求数据包，序号会自动加 1 。为了能够计算往返时间 RTT ，它会在报文的数据部分插入发送时间。然后，由 ICMP 协议将这个数据包连同地址 192.168.1.2 一起交给 IP 层。IP 层将以 192.168.1.2 作为目的地址，本机 IP 地址作为源地址，协议字段设置为 1 表示是 ICMP 协议，再加上一些其他控制信息，构建 一个IP 数据包。接下来，需要加入 MAC 头。如果在本地 ARP 映射表中查找出 IP 地址 192.168.1.2 所对应的 MAC地址，则可以直接使用；如果没有，则需要发送 ARP 协议查询 MAC 地址，获得 MAC 地址后，由数据链路层构建一个	数据帧，目的地址是 IP 层传过来的 MAC 地址，源地址则是本机的 MAC 地址；还要附加上一些控制信息，依据以太网的介质访问规则，将它们传送出去。主机 B 收到这个数据帧后，先检查它的目的 MAC 地址，并和本机的 MAC 地址对比，如符合，则接收，否则就丢弃。接收后检查该数据帧，将 IP 数据包从帧中提取出来，交给本机的 IP 层。同样，IP 层检查后，将有用的信息提取后交给 ICMP 协议。主机 B 会构建一个 ICMP 回送响应消息数据包，回送响应数据包的类型字段为 0 ，序号为接收到的请求数据包中的序号，然后再发送出去给主机 A。在规定的时候间内，源主机如果没有接到 ICMP 的应答包，则说明目标主机不可达；如果接收到了ICMP 回送响应消息，则说明目标主机可达。此时，源主机会检查，用当前时刻减去该数据包最初从源主机上发出的时刻，就是 ICMP 数据包的时间延迟。
    
    traceroute —— 差错报文类型的使用
	
	
	A的icmp到了B后，B为啥会自动给A一个回执0？这是操作系统的底层设计吗？
        如果说的“回执0”是指 ICMP 类型为 0 的话，那么 B 收到 A 的回送请求（类型为8） ICMP 报
        文，B 主机操作系统协议栈发现是个回送请求 ICMP 报文，那么协议栈就会组装一个回送应答（类型为
        0）的 IMCP 回应给 A。

http基础知识

1.常见状态码及分类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1××：服务器收到请求
2××：请求成功，如200
3××：重定向，如302
4××：客户端错误：如404
5××：服务端错误：如500

常见状态码：
200 成功
204 No Content
206 Partial Content
301 永久重定向(配合location,浏览器自动处理)
302 临时重定向(配合location,浏览器自动处理)
304 资源未被修改 服务器返回此响应时，不会返回网页内容(缓存)。
400 Bad Request
404 资源未找到
403 没有权限
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 网关超时

2.http methods

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1.传统的methods
	get 获取服务器的数据
	post 向服务器提交数据
	简单的网页，就这两个操作
	
2.现在的methods
	get 获取数据
	post 新建数据
	patch/put 更新数据
	delete 删除数据
	
3.Restful API(一种较新的早已推广使用的API设计方法)
	传统API设计：把每个url当做一个功能
	Restful API设计：把每个url当作一个唯一的资源
	如何设计一个资源
		尽量不用url参数 e.g 传统：/api/list?pageIndex=2 Restful API设计：/api/list/2
		用method表示操作类型 e.g 传统：post请求 /api/create-blog Restful API设计：/api/blog

3.http headers

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
常见的Request Headers
	Accept 浏览器可接受的数据格式
	Accept-Encodeing 浏览器可接收的压缩算法，如gzip
	Accept-Languange 浏览器可接收的语言，如zh-CN
	Connection:Keep-alive 一次TCP连接重复使用
	cookie 浏览器自带
	Host 请求的域名
	User-Agent(简称UA)浏览器信息或者客户端一些其他的信息
	Content-type 发送数据的格式，如application/json
	
常见的Response Headers
	Content-type 返回数据的格式，如application/json
	Content-length返回数据的大小，多少字节
	Content-Encoding 返回数据的压缩算法，如gzip
	Set-Cookie 服务端修改cookie
	
自定义header(C/S皆可)

缓存相关的headers
Cache-Control Expires
Last-Modified If-Modified-Since
Etag If-None-Match

4.http 缓存

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
1.缓存介绍 
	优化网络请求的时间消耗、一般静态资源可以被缓存(js css img)(含hash后缀)
	
2.http缓存策略(强制缓存+协商缓存)
	强制缓存：服务端控制Response Headers传过来的Cache-Control 在本地缓存(disk cache)中实现
    	cache-control常见值：max-age（最大维持缓存时间）、no-cache（不用强制缓存）、no-store（所有缓存都不使用）、private（仅允许个人终端用户缓存）、public（允许中间路由网关缓存）
    	
	协商(对比)缓存:服务端缓存策略(服务器判断客户端资源，是否和服务端资源(资源标识)一样) 一致就返回304，否则返回200和最新的资源
	资源标识
	Last-Modified 资源的最后修改时间
		原理：再次请求，Request Headers带着If-Modified-Since(===Last-Modified) 经服务器判断返回304或返回新的资源以及Last-Modified
		
	Etag 资源的唯一标识 和Last-Modified原理一样 If-None-Match（===Etag）  
	两者共存会优先使用Etag,Last-Modified只能精确到秒级 且如果资源被重复生成，而内容不变，则Etag更精确。
	
3.刷新操作方式，对缓存的影响
	1.正常刷新：地址栏输入url,跳转链接，前进后退等
	2.手动刷新：F5,点击刷新按钮或右键菜单刷新
	3.强制刷新：ctrl + F5
	
	1.正常操作：强制缓存有效(客户端实现)，协商缓存有效(服务器端)
	2.手动刷新：强制缓存失效，协商缓存有效
	3.强制刷新：都失效

4sEAnx.png

可靠传输 ——TCP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
HTTP 是基于 TCP 协议传输的，所以在这我们先了解下 TCP 协议。
首先，源端口号和目标端口号是不可少的，如果没有这两个端口号，数据就不知道应该发给哪个应用。
接下来有包的序号，这个是为了解决包乱序的问题。
还有应该有的是确认号，目的是确认发出去对方是否有收到。如果没有收到就应该重新发送，直到送
达，这个是为了解决不丢包的问题。
接下来还有一些状态位。例如 SYN 是发起一个连接， ACK 是回复， RST 是重新连接， FIN 是
结束连接等。TCP 是面向连接的，因而双方要维护连接的状态，这些带状态位的包的发送，会引起双方
的状态变更。
还有一个重要的就是窗口大小。TCP 要做流量控制，通信双方各声明一个窗口（缓存大小），标识自己
当前能够的处理能力，别发送的太快，撑死我，也别发的太慢，饿死我。
除了做流量控制以外，TCP还会做拥塞控制，对于真正的通路堵车不堵车，它无能为力，唯一能做的就
是控制自己，也即控制发送的速度。不能改变世界，就改变自己嘛。

TCP 传输数据之前，要先三次握手建立连接：在 HTTP 传输数据之前，首先需要 TCP 建立连接，TCP 连接的建立，通常称为三次握手。
三次握手目的是保证双方都有发送和接收的能力。(即保证客户端与服务端都成功的一发一收)
如果 HTTP 请求消息比较长，超过了 MSS 的长度(数据的最大长度)，这时 TCP 就需要把 HTTP 的数据拆解成一块块
的数据发送，而不是一次性发送所有数据。
MTU ：一个网络包的最大长度，以太网中一般为 1500 字节。
MSS ：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度。

在双方建立了连接后，TCP 报文中的数据部分就是存放 HTTP 头部+数据(http报文)，组装好 TCP 报文之后，就
需交给下面的网络层处理。

远程定位 ——IP

1
2
3
4
5
TCP 模块在执行连接、收发、断开等各阶段操作时，都需要委托 IP 模块将数据封装成网络包发送给通信对象。
在 IP 协议里面需要有源地址 IP 和 目标地址 IP：
源地址IP，即是客户端输出的 IP 地址；
目标地址，即通过 DNS 域名解析得到的 Web 服务器 IP。
因为 HTTP 是经过 TCP 传输的，所以在 IP 包头的协议号，要填写为 06 （十六进制），表示协议为TCP。

两点传输 ——MAC

1
2
3
4
5
6
7
8
9
10
11
12
生成了 IP 头部之后，接下来网络包还需要在 IP 头部的前面加上 MAC 头部。
MAC 头部是以太网使用的头部，它包含了接收方和发送方的 MAC 地址等信息。
一般在 TCP/IP 通信里，MAC 包头的协议类型只使用：
0800 ： IP 协议
0806 ： ARP 协议
发送方的 MAC 地址获取就比较简单了，MAC 地址是在网卡生产时写入到 ROM 里的，只要将这个值读
取出来写入到 MAC 头部就可以了。
接收方的 MAC 地址就有点复杂了，只要告诉以太网对方的 MAC 的地址，以太网就会帮我们把包发送过去，那么很显然这里应该填写对方的 MAC 地址。
所以先得搞清楚应该把包发给谁，这个只要查一下路由表就知道了。在路由表中找到相匹配的条目，然后把包发给 Gateway 列中的 IP 地址就可以了。

不知道对方 MAC 地址？不知道就喊呗。此时就需要 ARP 协议帮我们找到路由器的 MAC 地址。ARP 协议会在以太网中以广播的形式，对以太网所有的设备喊出：“这个 IP 地址是谁的？请把你的MAC 地址告诉我”。然后就会有人回答：“这个 IP 地址是我的，我的 MAC 地址是 XXXX”。如果对方和自己处于同一个子网中，那么通过上面的操作就可以得到对方的 MAC 地址。然后，我们将这个 MAC 地址写入 MAC 头部，MAC 头部就完成了。
放心，在后续操作系统会把本次查询结果放到一块叫做 ARP 缓存的内存空间留着以后用，不过缓存的时间就几分钟。也就是说，在发包时：先查询 ARP 缓存，如果其中已经保存了对方的 MAC 地址，就不需要发送 ARP 查询，直接使用ARP 缓存中的地址。而当 ARP 缓存中不存在对方 MAC 地址时，则发送 ARP 广播查询。

出口 —— 网卡

1
IP 生成的网络包只是存放在内存中的一串二进制数字信息，没有办法直接发送给对方。因此，我们需要将数字信息转换为电信号，才能在网线上传输，也就是说，这才是真正的数据发送过程。负责执行这一操作的是网卡，要控制网卡还需要靠网卡驱动程序。网卡驱动从 IP 模块获取到包之后，会将其复制到网卡内的缓存区中，接着会在其开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列(末尾的 FCS （帧校验序列）用来检查包传输过程是否有损坏)。最后网卡会将包转为电信号，通过网线发送出去

送别者 —— 交换机

1
2
3
4
5
6
下面来看一下包是如何通过交换机的。交换机的设计是将网络包原样转发到目的地。交换机工作在MAC 层，也称为二层网络设备。
首先，电信号到达网线接口，交换机里的模块进行接收，接下来交换机里的模块将电信号转换为数字信号。然后通过包末尾的 FCS 校验错误，如果没问题则放到缓冲区。这部分操作基本和计算机的网卡相同，但交换机的工作方式和网卡不同。计算机的网卡本身具有 MAC 地址，并通过核对收到的包的接收方 MAC 地址判断是不是发给自己的，如果不是发给自己的则丢弃；相对地，交换机的端口不核对接收方 MAC 地址，而是直接接收所有的包并存放到缓冲区中。因此，和网卡不同，交换机的端口不具有 MAC 地址。将包存入缓冲区后，接下来需要查询一下这个包的接收方 MAC 地址是否已经在 MAC 地址表中有记录了。交换机的 MAC 地址表主要包含两个信息：一个是设备的 MAC 地址，另一个是该设备连接在交换机的哪个端口上.所以，交换机根据 MAC 地址表查找 MAC 地址，然后将信号发送到相应的端口。地址表中找不到指定的 MAC 地址。这可能是因为具有该地址的设备还没有向交换机发送过包，或者这个设备一段时间没有工作导致地址被从地址表中删除了。
这种情况下，交换机无法判断应该把包转发到哪个端口，只能将包转发到除了源端口之外的所有端口上，无论该设备连接在哪个端口上都能收到这个包。这样做不会产生什么问题，因为以太网的设计本来就是将包发送到整个网络的，然后只有相应的接收者才接收包，而其他设备则会忽略这个包。有人会说：“这样做会发送多余的包，会不会造成网络拥塞呢？”其实完全不用过于担心，因为发送了包之后目标设备会作出响应，只要返回了响应包，交换机就可以将它的地址写入 MAC 地址表，下次也就不需要把包发到所有端口了。局域网中每秒可以传输上千个包，多出一两个包并无大碍。此外，如果接收方 MAC 地址是一个广播地址，那么交换机会将包发送到除源端口之外的所有端口。
以下两个属于广播地址：
MAC 地址中的 FF:FF:FF:FF:FF:FF
IP 地址中的 255.255.255.255

出境大门 —— 路由器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
路由器与交换机的区别
网络包经过交换机之后，现在到达了路由器，并在此被转发到下一个路由器或目标设备。
这一步转发的工作原理和交换机类似，也是通过查表判断包转发的目标。
不过在具体的操作过程上，路由器和交换机是有区别的。
因为路由器是基于 IP 设计的，俗称三层网络设备，路由器的各个端口都具有 MAC 地址和 IP 地
址；而交换机是基于以太网设计的，俗称二层网络设备，交换机的端口不具有 MAC 地址。
路由器基本原理
路由器的端口具有 MAC 地址，因此它就能够成为以太网的发送方和接收方；同时还具有 IP 地址，从这
个意义上来说，它和计算机的网卡是一样的。
当转发包时，首先路由器端口会接收发给自己的以太网包，然后路由表查询转发目标，再由相应的端口
作为发送方将以太网包发送出去。

路由器的包接收操作
首先，电信号到达网线接口部分，路由器中的模块会将电信号转成数字信号，然后通过包末尾的 FCS
进行错误校验。如果没问题则检查 MAC 头部中的接收方 MAC 地址，看看是不是发给自己的包，如果是就放到接收缓冲区中，否则就丢弃这个包。总的来说，路由器的端口都具有 MAC 地址，只接收与自身地址匹配的包，遇到不匹配的包则直接丢弃。
查询路由表确定输出端口
完成包接收操作之后，路由器就会去掉包开头的 MAC 头部。
MAC 头部的作用就是将包送达路由器，其中的接收方 MAC 地址就是路由器端口的 MAC 地址。因此，
当包到达路由器之后，MAC 头部的任务就完成了，于是 MAC 头部就会被丢弃。
接下来，路由器会根据 MAC 头部后方的 IP 头部中的内容进行包的转发操作。
转发操作分为几个阶段，首先是查询路由表判断转发目标。
判断转发目标的第一步，就是根据包的接收方 IP 地址查询路由表中的目标地址栏，以找到相匹配的记
录。路由匹配和前面讲的一样，每个条目的子网掩码和 192.168.1.100 IP 做 & 与运算后，得到的结果与对应条目的目标地址进行匹配，如果匹配就会作为候选转发目标，如果不匹配就继续与下个条目进行路由匹配。

路由器的发送操作
接下来就会进入包的发送操作。
首先，我们需要根据路由表的网关列判断对方的地址。
如果网关是一个 IP 地址，则这个IP 地址就是我们要转发到的目标地址，还未抵达终点，还需继续需要路由器转发。
如果网关为空，则 IP 头部中的接收方 IP 地址就是要转发到的目标地址，也是就终于找到 IP 包头里的目标地址了，说明已抵达终点。知道对方的 IP 地址之后，接下来需要通过 ARP 协议根据 IP 地址查询 MAC 地址，并将查询的结果作
为接收方 MAC 地址。路由器也有 ARP 缓存，因此首先会在 ARP 缓存中查询，如果找不到则发送 ARP 查询请求。接下来是发送方 MAC 地址字段，这里填写输出端口的 MAC 地址。还有一个以太类型字段，填写0080 （十六进制）表示 IP 协议。网络包完成后，接下来会将其转换成电信号并通过端口发送出去。这一步的工作过程和计算机也是相同的。发送出去的网络包会通过交换机到达下一个路由器。由于接收方 MAC 地址就是下一个路由器的地址，所以交换机会根据这一地址将包传输到下一个路由器。接下来，下一个路由器会将包转发给再下一个路由器，经过层层转发之后，网络包就到达了最终的目的地。
不知你发现了没有，在网络包传输的过程中，源 IP 和目标 IP 始终是不会变的，一直变化的是 MAC 地 址，因为需要 MAC 地址在以太网内进行两个设备之间的包传输。

互相扒皮 —— 服务器与客户端

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
数据包抵达了服务器，服务器肯定高兴呀，正所谓有朋自远方来，不亦乐乎？
服务器高兴的不得了，于是开始扒数据包的皮！就好像你收到快递，能不兴奋吗？
数据包抵达服务器后，服务器会先扒开数据包的 MAC 头部，查看是否和服务器自己的 MAC 地址符
合，符合就将包收起来。
接着继续扒开数据包的 IP 头，发现 IP 地址符合，根据 IP 头中协议项，知道自己上层是 TCP 协议。
于是，扒开 TCP 的头，里面有序列号，需要看一看这个序列包是不是我想要的，如果是就放入缓存中
然后返回一个 ACK，如果不是就丢弃。TCP头部里面还有端口号， HTTP 的服务器正在监听这个端口
号。
于是，服务器自然就知道是 HTTP 进程想要这个包，于是就将包发给 HTTP 进程。
服务器的 HTTP 进程看到，原来这个请求是要访问一个页面，于是就把这个网页封装在 HTTP 响应报
文里。

HTTP 响应报文也需要穿上 TCP、IP、MAC 头部，不过这次是源地址是服务器 IP 地址，目的地址是客
户端 IP 地址。
穿好头部衣服后，从网卡出去，交由交换机转发到出城的路由器，路由器就把响应数据包发到了下一个
路由器，就这样跳啊跳。
最后跳到了客户端的城门把手的路由器，路由器扒开 IP 头部发现是要找城内的人，于是又把包发给了
城内的交换机，再由交换机转发到客户端。
客户端收到了服务器的响应数据包后，同样也非常的高兴，客户能拆快递了！
于是，客户端开始扒皮，把收到的数据包的皮扒剩 HTTP 响应报文后，交给浏览器去渲染页面，一份特
别的数据包快递，就这样显示出来了！
最后，客户端要离开了，向服务器发起了 TCP 四次挥手，至此双方的连接就断开了。

TCP 三次握手和四次挥手的面试题型

赏

Thanks

支付宝
微信

扫一扫，分享到微信

微信分享二维码
-->
-->

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

很快啊~'<br><br>'敬请期待