计网总结

Question

物理层

数据链路层

三个基本问题

• 封装成帧
• 透明传输
• 差错检测

PPP 帧与 Mac 帧的区别

ppp 属于广域网范畴，MAC 是局域网范畴，按实际情况和环境就选用不同的协议，ppp支持的网络结构只能是点对点，mac 支持多点对多点。

以太网中用 mac，远程的话就用 ppp（如ADSL拨号，就是基于ppp的）。

ppp 是点到点协议 ,逻辑上相连的就一台设备，因此不需要寻址, 目标地址为广播地址, PPP中前6个字节就是目标地址。

网络层

提供主机间的逻辑通信

ARP

ARP 是解决 同一个局域网 中主机或路由器IP地址到硬件地址的映射问题。

每台主机都有一个ARP高速缓存，里面存放着一个从IP地址到硬件地址的映射表，并且动态更新

步骤：

• ARP 进程在局域网上广播发送一个ARP请求分组。（附带上自己的IP地址和硬件地址以及目的地址）
• 在局域网上所有主机上运行ARP进程都会收到这个 ARP 分组
• 主机B的IP地址和ARP请求分组中要查询的一致，就收下这个请求分组，并且向主机A发送ARP响应分组
• 主机A收到主机B的 ARP 响应分组后，在自己的 ARP 高速缓存中写入主机B的IP地址到硬件地址的映射

ICMP

ICMP 报文是装在IP数据报中的，作为其中的数据部分。

应用：

• ping
• tracerouter

路由选择协议

内部网关协议IGP

RIP：基于距离向量

优点：

• 配置简单
• 开销小

缺点

• 大量广播。RIP向所有邻居每隔30秒广播一次完整的路由表,将占用宝贵的带宽资源,在较慢的广域网链路上尤其有问题｡
• 没有成本概念｡RIP没有网络延迟和链路成本的概念｡当采用RIP时,路由/转发的决定只是基于跳线,这样,很容易导致无法选择最佳路由｡例如,一条链路拥有较高的带宽,但是,跳数较多,从而不能被选择｡
• 支持的网络规模有限｡由于RIP路由协议最多只支持16个步跳,当超过该跳数时,网络将认为无法到达｡因此,RIP只能适用于规模较少的网络｡

OSPF:最短路径优先

优点：

• 快速收敛｡OSPF是真正的LOOP- FREE(无路由自环)路由协议｡源自其算法本身——链路状态及最短路径树算法,OSPF收敛速度快,能够在最短的时间内将路由变化传递到整个自治系统｡
• 区域划分｡提出区域(Area)划分的概念,将自治系统划分为不同区域后,通过区域之间的对路由信息的摘要,大大减少了需传递的路由信息数量,也使得路由信息不会随网络规模的扩大而急剧膨胀｡
• 开销控制｡将协议自身的开销控制到最小｡用于发现和维护邻居关系的是定期发送的不含路由信息的hello报文,非常短小｡包含路由信息的报文是触发更新的机制,而且只有在路由变化时才会发送｡但为了增强协议的健壮性,每1800秒全部重发一次｡
• 安全性高｡良好的安全性,OSPF支持基于接口的明文及MD5 验证｡

缺点：

• 配置相对复杂｡由于网络区域划分和网络属性的复杂性,需要网络分析员有较高的网络知识水平才能配置和管理OSPF网络｡
• 路由负载均衡能力较弱｡OSPF虽然能根据接口的速率､连接可靠性等信息,自动生成接口路由优先级,但在通往同一目的的不同优先级路由中,OSPF只选择优先级较高的转发,不同优先级的路由中,不能实现负载分担｡只有相同优先级的,才能达到负载均衡的目的

外部网关协议EGP

BGP

高度抽象，把AS自治系统抽象成一个路由，它就是一个基于路径向量路由选择协议。每个AS系统会有一个或者多个路由器充当发言人，根据收到的路由信息拓扑出AS的树型结构连通图

NAT

运输层

提供应用进程间端到端的逻辑通信

UDP

• 无连接，不可靠，面向报文
• 无拥塞控制，支持一对一，一对多，多对多，多对一，首部开销小
• 检验和把首部和数据部分一起都检验

UDP丢包

丢包的主要原因

1. 接收端处理时间过长导致丢包：调用recv方法接收端收到数据后，处理数据花了一些时间，处理完后再次调用recv方法，在这二次调用间隔里，发过来的包可能丢失。对于这种情况可以修改接收端，将包接收后存入一个缓冲区，然后迅速返回继续recv.
2. 发送的包较大，超过接受者缓存导致丢包：包超过mtu size数倍，几个大的udp包可能会超过接收者的缓冲，导致丢包
3. 发送的包频率太快：虽然每个包的大小都小于mtu size 但是频率太快

解决方案

• 可以修改接收端，将包接收后存入一个缓冲区
• 对于超过缓存大小的包，可以选择直接接受
• 通过流量控制

TCP

• 面向连接，可靠
• 面向字节流
• 全双工通信

TCP粘包拆包

• 粘包拆包出现的原因 ： 因为TCP面向字节流传输的，发送端需要等缓冲区满才发送出去，造成粘包。接收方不及时接收缓冲区的包，造成多个包接收
• 非工程性的解决方法：
  • 利用TCP提供了强制数据立即传送的操作指令push
    缺点：但它关闭了优化算法，降低了网络发送效率，影响应用程序的性能
  • 精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据
    缺点：只能减少出现粘包的可能性，但并不能完全避免粘包。因为当发送频率较高时，或由于网络突发可能使某个时间段数据包到达接收方较快，接收方还是有可能来不及接收，从而导致粘包。
  • 两次send函数之间添加 sleep函数
    缺点：会降低数据传输效率
• 工程型的解决方法：
  • 1.消息定长，例如每个报文的大小为固定长度200字节,如果不够，空位补空格；
  • 2.在包尾增加回车换行符进行分割（模仿帧的设计方式）；
  • 3.将消息分为消息头和消息体，消息头中包含表示消息总长度（或者消息体长度）的字段，通常设计思路是消息头的第一个字段用int来表示消息的总长度；（在pushsdk中使用此种方式利用了 Netty 中的 LengthFieldBasedFrameDecoder 解码器实现)
  • 4.更复杂的应用层协议；
  • 添加标志字段，在每次发送数据是添加标记字段：A： =>size 标记数据长度的方式 B：特定标记字段标记数据的结尾（模仿帧的设计方式）＝>结束符的方式
  • 定义应用层的数据通讯协议 ：=>如果数据按照一定的方式存储或着优加密的需求， 可以通过自己定制 数据通讯协议对数据封装，并实现自己的数据 封包｜ 拆包函数。

为了解决TCP粘包拆包的问题，Netty 默认提供了多种编码器来处理

根据MTU拆分成多个数据报

http://blog.csdn.net/yusiguyuan/article/details/22782943

（TCP层的分段和IP层的分片之间的关系 & MTU和MSS之间的关系）

三次握手

在客户端和服务端都创建好传输控制模块 TCB 的条件下：

• 客户端向服务端发出连接请求报文段
• 服务端接受到连接请求报文段后，同意建立连接就返回一个确认报文段
• 客户端的 TCP 客户进程收到确认后，还需要向服务端发出确认报文段

传输控制模块 TCB：存储了每一个连接中的一些重要信息，比如 TCP 连接表，重传队列指针，当前发送的序列号等等。

为什么是三次握手？

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误

会有这样的一种情况：client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用三次握手，那么只要 server 发出确认，新的连接就建立了。

由于现在 client 并没有发出建立连接的请求，因此不会理睬server的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采用三次握手的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。。主要目的防止server端一直等待，浪费资源。

四次挥手

• 1.客户端发送连接释放报文段，并且停止发送数据，主动关闭 TCP 连接，然后进入等待状态，等待服务端的确认
• 2.服务端收到连接释放报文段之后，立即发送确认报文段，然后进入关闭等待状态。并且 TCP 服务器进程会通知高层应用进程。这个时候，客户端到服务端这个方向的连接就处于半关闭状态。
• 客户端收到确认报文段之后，等待服务端发出连接释放报文段
• 3.若服务端没有要向客户端发送的数据之后，应用进程会通知 TCP 释放连接。这个时候，服务端会发出连接释放报文段
• 4.客户端收到连接释放报文段之后，会返回一个确认报文段。然后自己进入时间等待状态，即等待一个时间才会最终进入关闭状态。
  • 为什么需要等待一个时间？
    • 一、为了保证客户端最后发送的一个报文段能够到达服务端
    • 二、防止已失效的连接请求报文段出现在本连接中
• 服务端只要收到了客户端最后一次的确认报文段就会进入关闭状态，结束这次TCP连接

为什么需要四次挥手？

确保数据能够完成传输。假设服务端收到连接释放报文段之后马上就释放连接，那么服务端还存在数据需要发送给客户端的话，就不能保证这些数据能够发送到客户端身上。因此需要等待服务端把数据发送完之后，由服务端发起一条连接释放报文段，也就是第三次挥手，最后由客户端发起确认，也就是第四次挥手，因此需要四次挥手才能确保数据能够完成完整的传输。

可靠传输的实现

TCP 可靠传输的实现

TCP为了提供可靠传输：

（1）首先，采用三次握手来建立 TCP 连接，四次握手来释放 TCP 连接，从而保证建立的传输信道是可靠的。

（2）其次，TCP 采用了连续 ARQ 协议（回退 N，Go-back-N；超时自动重传）来保证数据传输的正确性，使用滑动窗口协议来保证接方能够及时处理所接收到的数据，进行流量控制。

（3）最后，TCP 使用 慢开始、拥塞避免、快重传 和 快恢复 来进行拥塞控制，避免网络拥塞。

• 以字节为单位的滑动窗口
• 缓存机制
  • 发送缓存用来暂时存放：
    1.发送应用程序传送给发送方TCP准备的数据
    2.TCP已发送但尚未收到确认的数据。
  • 接收缓存用来暂时存放：
    1.按序到达的，但尚未被接收应用程序读取的数据。
    2.未按序到达的数据。
• 超时重传的时间选择

TCP流量控制原理

所谓流量控制就是让发送发送速率不要过快，让接收方来得及接收。利用滑动窗口机制就可以实施流量控制。

原理这就是 运用 TCP 报文段中的窗口大小字段来控制，发送方的发送窗口不可以大于接收方发回的窗口大小。

考虑一种特殊的情况，就是接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送放将发送窗口设置为0，停止发送数据。之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的，那么发送方的发送窗口就一直为零导致死锁。

​解决这个问题，TCP 为每一个连接设置一个持续计时器（persistence timer）。只要TCP的一方收到对方的零窗口通知，就启动该计时器，周期性的发送一个零窗口探测报文段。对方就在确认这个报文的时候给出现在的窗口大小（注意：TCP 规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段）。

拥塞控制

慢开始和拥塞避免

拥塞窗口：cwnd（Congestion Window）是 发送端 根据自己估计的网络拥塞程度而设置的窗口值，是来自发送端的流量控制。

如果发现 RTT 在增大，Vegas 就认为网络正在发生拥塞

慢开始原理

1. ​ 当主机开始发送数据时，如果立即将较大的发送窗口的全部数据字节都注入到网络中，那么由于不清楚网络的情况，有可能引其网络拥塞
2. ​ 比较好的方法是试探一下，即从小到达逐渐增大发送端的拥塞控制窗口数值
3. ​ 通常在刚刚开始发送报文段时可先将拥塞窗口 cwnd(拥塞窗口)设置为一个最大报文段的 MSS 的数值。在每收到一个对新报文段确认后，将拥塞窗口增加至多一个 MSS 的数值，当 rwind（接收窗口）足够大的时候，为了防止拥塞窗口 cwind 的增长引起网络拥塞，还需要另外一个变量---慢开始门限 ssthresh

拥塞避免原理

1. ​ 让拥塞窗口 cwnd 缓慢增大，每经过一个往返时间RTT就把发送方的拥塞窗口 cwnd 加 1，而不是加倍。按线性规律缓慢增长。

无论，在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞之后，就会把门限 ssthresh 设置为发送方发送窗口值的一半

快重传和快恢复

快重传算法：在某些情况下更早的重传丢失的报文段（如果当发送端接收到三个重复的确认 ACK 时，则断定分组丢失，立即重传丢失的报文段，而不必等待重传计时器超时）。

例如：M1，M2，M3 -----> M1、M3、缺失 M2，则接收方向发送方持续发送 M2 重复确认，当发送方收到 M2 的三次重复确认，则认为M2报文丢失，启动快重传机制，重传数据，其他数据发送数据放入队列，待快重传结束后再正常传输。

快恢复算法有以下两个要点：

1. ​ 当发送方连续收到接收方发来的三个重复确认时，就执行“乘法减小”算法，把慢开始门限减半，这是为了预防网络发生拥塞。
2. ​ 由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是把 cwnd（拥塞窗口）值设置为慢开始门限减半后的值，然后开始执行拥塞避免算法，使拥塞窗口的线性增大。

ps：超时重传是 TCP 协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。

应用层

协议规定应用进程间标准

DNS

域名解析成IP地址

域名服务器间的查询

• 迭代查询
• 递归查询

域名服务器广泛使用高速缓存，减轻根域名服务器以及减少因特网上 DNS 查询报文数量

DHCP

整体流程：主机A 以广播形式发送报文，DHCP 中继（通常是一个路由器）收到报文之后，以单播形式转发此报文给 DHCP 服务器，然后又通过中继回发提供报文给主机 A。DHCP 客户就可以使用被分配的 IP 地址，但是有一定的租用期

详细的工作步骤：

• DHCP 服务器被动打开UDP端口67，等待客户端发送报文
• DHCP 客户从UDP端口68发送DHCP发现报文
• 凡是收到DHCP发现报文的DHCP服务器都发出DHCP提供报文（DHCP客户端可以收到多个DHCP提供报文）
• DHCP从几个DHCP服务器中选择一个，并向选择的DHCP服务器发送DHCP请求报文
• 被选择的DHCP服务器发送确认报文。这个时候，DHCP客户就可以使用IP地址了。这是一种已绑定的状态，即DHCP客户的IP地址和硬件地址已经绑定了。这个时候DHCP客户就会根据服务器提供的租用期设置两个计时器，分别在0.5T和0.85T的时候，请求更新租用期。
• 租用期过了一半，DHCP就会发送请求报文要求更新租用期
• DHCP服务器若同意，则发回确认报文，得到新的租用期，重新设置计时器
• 若不同意，则发回否认报文。这时DHCP客户必须立即停止使用原来的IP地址，然后重新申请新的IP地址。
• 若服务器不响应，则在0.85T的时候重新执行以上操作
• DHCP客户可以随时提前终止服务器所提供的租用期，只需要发送释放报文即可。

HTTP

HTTP 协议是无状态的，即同一个客户第二次访问同一个服务器上的页面的时候，服务器响应时间与第一次响应时间相同。

HTTP请求报文是作为TCP三次握手的第三个报文的数据

HTTP1.0

非持续连接：每次请求完就会关闭 TCP 连接

缺点：

• 每请求一个文档就需要两倍 RTT 的开销。
• 每一次建立新的TCP连接都要分配缓存和变量
  • 现在浏览器都提供了能够打开 5-10 个并行的 TCP 连接，每一个 TCP 连接处理一个客户请求

HTTP1.1

使用持续连接：就是万维网服务器在发送响应后仍然在一段时间内保持这条连接，使同一个客户可以继续在这条连接上传送后续的 HTTP 报文

两种工作方式：

• 非流水线方式
  • 特点：
  • 客户收到前一个响应后才能发出下一个请求
  • 缺点：
  • 服务器在发送完一个对象后，TCP 连接会空闲，浪费资源
• 流水线方式
  • 特点：
  • 客户收到HTTP响应报文之前就可以继续发送新的请求报文。
  • 优点：
  • TCP连接的空闲时间减少

两者区别

http://blog.csdn.net/forgotaboutgirl/article/details/6936982

• 可扩展性
• 缓存
• 带宽优化
• 长连接
• 消息传递
• Host头域
• 错误提示
• 内容协商

HTTP2.0

多路复用

HTTP 2.0 使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比 HTTP 1.1 大了好几个数量级。当然 HTTP 1.1 也可以多建立几个 TCP 连接，来支持处理更多并发的请求，但是创建 TCP 连接本身也是有开销的。

关于多路复用，可以稍微扯上NIO

数据压缩

HTTP 1.1 不支持 header 数据的压缩，HTTP 2.0 使用 HPACK 算法对 header 的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

输入URL之后的网络操作

输入 URL 之后的网络操作：https://segmentfault.com/a/1190000006879700

DNS 解析过程中同时存在 UDP 和 TCP 请求：http://www.cnblogs.com/549294286/p/5172435.html

• DNS 解析
  • 可扯上为什么 DNS 解析过程中同时存在 UDP 和 TCP 请求
  • 可扯上 DNS 优化，即缓存 ：浏览器缓存，系统缓存，路由器缓存，IPS 服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存
  • 可扯上 DNS 负载均衡，即 DNS 重定向。CDN 技术就是利用 DNS 重定向技术的，
• 建立 TCP 连接
• 发送 HTTP 请求
• 发送所需文件给客户端
• 释放连接
• 浏览器渲染 WEB 资源