计算机网络

场景问题

键入网络到网页显示

1. DHCP获取IP地址
   • DHCP基于UDP， 端口67 68
   • 没有联网的情况下，先配置网络
2. 解析URL
   • URL组成结构(图片来源于JavaGuide)
   • 协议、域名、端口、路径资源、参数、描点(以#开头，不会作为请求的一部分发出给服务端)
3. 构造HTTP请求
4. DNS查询
   • 域名系统中 越靠右表示层级越高
   • 查询顺序: 浏览器缓存 -> 操作系统缓存 -> hosts文件 -> 本地DNS服务器(网络查询)
   • DNS协议
     • 基于UDP， 端口53
     • 递归到本地DNS服务器， 由其完成后续迭代。
     • 根域名服务器 -> 顶级域名服务器 -> 权威域名服务器
5. 建立TCP连接
   • 三次握手建立连接(确保双方都有发送和接收的能力)
   • TCP -> IP -> MAC -> 网卡 -> 交换机 -> 路由器
   • IP 完成路由
     • ARP 完成 IP地址 到 MAC地址的转换
   • MAC 寻址
   • 交换机仅完成数据包的转发， 无MAC地址
   • 路由器根据IP进行转发，在路由表上进行每个条目与子网掩码进行与运算再进行路由，无匹配则使用默认路由
     • 路由依赖于 内部网关协议 RIP OSPF 和 外部网关协议 BGP
   • 源IP与目标IP地址始终不变， MAC地址不停变化
6. HTTP请求页面
   • 发出目的端口为 80 / 443 的请求报文段
7. HTTP请求返回
8. 渲染页面
9. 主动关闭TCP连接或等待服务端的关闭请求

服务端出现大量TIME_WAIT状态

1. HTTP没有使用长连接
   • HTTP 1.1开始默认开启 HTTP Keep-Alive
   • 客户端与服务端任意一方的HTTP Header中有 Connection:close 信息则无法使用长连接
   • 大多数的Web服务实现中，不管哪一方禁用了 HTTP Keep-Alive 都是服务端主动关闭连接
2. HTTP长连接超时
   • 长连接超时，也会导致服务端主动关闭连接
3. HTTP长连接请求数量达到上限
   • Web服务端通常有多个参数来定义一条HTTP长连接上最大能处理的请求数量，当超过最大限制时，就会主动关闭连接

服务器端出现大量CLOSE_WAIT

• 服务端没有主动调用 close 函数关闭连接
  • 有新连接到来时，没有调用 accept 获取该链接的 socket 导致客户端主动断开连接而服务端却无处理。
  • 通过 accept 获取已连接的 socket 后 没有注册到 epoll ，导致后续收到 FIN 报文时，服务端无法感知该事件。

已建立连接的客户端宕机

• TCP保活机制
  • 一段时间内、没有任何连接相关活动，则发出探测报文，几个探测报文内没有响应则判定为连接死亡
  • 探测报文可能遇到的场景
    • 对端主机正常工作： TCP保活机制重置
    • 对端主机宕机并重启： 对端没有该链接有效信息，产生RST报文重置链接
    • 对端主机宕机：多次不可达，TCP报告该链接已死亡
• HTTP保活机制
  • 由应用层自己实现的心跳机制，短时间内没有新的请求则触发回调函数来释放连接

已建立连接的服务端进程崩溃

• TCP连接有内核维护，服务端进程崩溃后由内核完成四次挥手

HTTP KeepAlive 与 TCP KeepAlive]

• HTTP Keep Alive 由应用层实现(用户态)，称为HTTP长连接
  • 使用同一个TCP链接来发送和接收多个HTTP请求/应答，避免连接建立和释放的开销
  • 特点是只要没有一端明确提出断开连接，则保持连接状态
  • 为HTTP流水线提供了实现基础
    • 客户端一次发出多个请求，发送过程中不需先等待服务器的响应
  • 上一个请求完成后，一定时间内没有新的请求，则触发回调函数来释放连接
• TCP Keepalive 是TCP层实现(内核态)，称为TCP保活机制
  • 两端一直没有数据交互，则发送探测报文检测对端是否在线，以此决定是否关闭连接
• 总结
  • HTTP Keep Alive 是用户态实现的，减少HTTP短连接的开销，自定义了一段时间内没有新请求则释放
  • TCP Keepalive 是内核态实现的，只考虑对端是否存活，存活则保持连接

HTTP

HTTP状态码

1. 1xx 类状态码属于提示信息，是协议处理的一种中间状态，很少使用
2. 2xx 类状态码表示服务器成功处理了客户端请求
   • 200 OK 表示一切正常
   • 204 No Content 也是正常，但响应头没有body数据
3. 3xx 类状态码表示客户端需要重定向
   • 301 永久重定向，说明资源已经不存在了
   • 302 临时重定向，说明资源还在，但暂时需要另一个URL来访问
   • 304 Not Modified 不具有跳转含义，表示客户端可以继续使用缓存资源
4. 4xx 表示客户端请求报文有误
   • 400 笼统的表示客户端有错误
   • 403 Forbidden 表示服务器禁止访问资源
   • 404 Not Found 表示请求的资源在服务器上不存在或者未找到
5. 5xx表示服务端处理时内部发生了错误
   • 500 笼统的表示服务端错误
   • 501 客户端请求的功能还不支持
   • 502 网关错误
   • 503 服务器当前正忙，稍后重试

GET与POST

1. GET
   • 语义是从服务器获取指定的资源
   • 不会修改服务器上的资源，安全且幂等，请求可以缓存，能够保存为书签
   • 一般参数在URL上
   • 其实是可以携带Body的，但规范上最好不要
2. POST
   • 语义上是根据请求的负载对指定资源进行处理
   • 会修改服务器上的资源，不安全不幂等，不会缓存，不能保存为书签
   • URL可以有参数
   • 一般参数在Body上

HTTP1.1

1. 新增了状态码
2. 支持管道传输，只要第一个请求发出去了，不必等其回来，可以继续发送第二个请求
3. 增加了部分首部信息
   • 更复杂的缓存
   • 长连接
   • Host
   • 范围请求
   • 压缩
   • ...

HTTPS

1. HTTPS 采用对称加密和非对称加密的混合加密算法
   • 通信建立前使用非对称加密算法交换对称加密算法的密钥
   • 通信后使用对称加密算法加密明文数据
   • 非对称加密算法使用两个密钥，公钥可以随意分发而私钥保密，解决了密钥交换问题但速度慢
   • 对称加密算法只有一个密钥，速度快但密钥交换不安全
2. 哈希算法+数字签名
   • 哈希算法计算内容的哈希值，哈希值唯一且不可逆推
   • 哈希算法可以保证内容不被篡改，但不能保证 {内容+哈希值} 不会被替换 缺少了客户端对收到的消息是否来自于服务端的证明
   • 通过非对称算法的双向加解密解决
     • 公钥加密 私钥解密 保证内容传输的安全
     • 私钥加密 公钥解密 保证消息不会被冒充
     • 加解密的对象是哈希值
3. 数字证书
   • 用来认证身份的合法性
4. SSL/TLS 加密握手
5. HTTPS 目前为止本身没有漏洞，但中间人攻击可能利用客户端漏洞，比如证书验证失败，但用户点击继续访问，或者被恶意导入伪造的证书
   • 像抓包工具都要手动植入证书

HTTP2

1. HTTP 1.1的问题
   1. 难以降低延迟
   2. 并发数量有限
   3. 队首阻塞
   4. HTTP首部巨大且重复
   5. 不支持服务器推送消息
   6. 常见优化手段
      • 图片的二进制数据编码后嵌入到 HTML CSS 文件中，减少网络请求次数
      • 多个小文件合并为一个大文件，减少网络请求次数，但小文件更新也会影响大文件
      • 同一个页面资源放到不同域名下，提高并发上限
2. 首部压缩
   • 避免冗余数据的重复性
   • HPACK算法
     • 静态字典
       • 61个常见字符串，比如 GET POST 200 等
     • 动态字典+哈弗曼编码
       • 62开始
       • 双方共同维护长字符串，如cookie
       • 缺点是只能在同一个链接上重复传输完全相同的HTTP首部
3. 二进制帧
   • 文本格式改成二进制格式传输
   • 一条消息可分为首部帧和负载帧来传输
   • 共定义了10种类型帧，一般就分为数据帧和控制帧
   • 并发传输
     • 多个Stream复用一个TCP连接达到并发效果
     • 一个数据包可以包含不同怪Stream的帧，以完成并发传输
     • 不同Stream的帧可以乱序发送，但同一个Stream内部的帧必须严格有序
     • HTTP2的并发只需要建立一次TCP连接，而HTTP/1.1需要建立许多TCP连接
     • 可以设置优先级
4. 服务器主动推送资源

HTTP3

1. HTTP2的缺点
   1. 队首阻塞： 多个请求塞在一个TCP连接中，丢包时整个TCP都要等待
   2. TCP与TLS的握手延迟： TCP三次握手和TLS四次握手
   3. 网络迁移需要重新连接： TCP连接用四元组确定
2. HTTP3(QUIC)
3. 无队首阻塞
   • QUIC是在应用层定义了UDP的数据包格式，实现了TCP协议的各种机制从而达成可靠传输
   • QUIC基于UDP，不关心数据包顺序，即使数据包丢失，直接重新传输一个新的数据包就可以了，而无需确认数据包的丢失
   • 单个数据包丢失只影响该数据包中包含的流
4. 更快的连接建立
   • QUIC内部包含了TLS，在帧中携带TLS记录，只需要1RTT内就可以完成握手
   • 二次连接可以直接携带握手信息，达成0RTT握手效果
   • 实际上就是因为在应用层实现，可以直接使用最新的学术研究，而不像TCP一样被中间件僵化了
5. 连接迁移
   • QUIC用连接ID来标记通信的端点，即使网络发生变化，只要持有上下文信息，就可以无缝使用原连接

Cookie

1. HTTP 1.1 引入
2. 作用
   1. 会话状态管理
   2. 个性化设置
   3. 浏览器行为跟踪
3. 分类
   • 会话期 Cookie: 浏览器关闭后自动删除
   • 持久性 Cookie: 指定过期时间
4. Session
   • 将用户信息存储在服务端
5. 浏览器禁用Cookie
   • 使用 Session
   • 将Cookie存入URL
6. cookie与session的选择
   • Cookie只能存储ASCII码，考虑复杂情况时选择Session
   • Cookie存在浏览器中，安全性相较于Session较低
   • 对于大型网站，用户信息存在Session中开销较大

缓存

1. 优点
   1. 缓解服务器压力
   2. 降低客户端获取资源的延迟
      • 缓存位于内存 读取更快
      • 缓存服务器在地理位置上可能离的更近
2. 方法
   • 代理服务器缓存
   • 客户端浏览器缓存
   • 中间件缓存
3. 缓存验证
   • ETag首部: ETag值和资源的最新ETag值一致表示资源有效，返回304 NOT MODIFIED
   • Last-Modified首部: 记录服务器资源修改的最晚时间，但时效性上最低是一秒

通信数据转发

1. 代理
   • 目的
     • 缓存
     • 负载均衡
     • 网络访问控制
     • 记录访问日志
   • 种类
     • 正向代理: 用户可以察觉
     • 反向代理: 位于服务器内部网络，用户无法察觉
2. 网关
   • 将HTTP转化为其他协议进行通信，从而请求其他非HTTP服务器的服务
3. 隧道
   • 在客户端和服务器之间建立一条安全的通信线路

TCP

什么是TCP

• 面向连接的、可靠的、基于字节流的传输层通信协议
  • 面向连接： 一对一通信
  • 可靠的： 无论网络链路发生什么样的变化，TCP都可以保证一个报文一定被接收
  • 字节流： 用户消息通过TCP协议进行传输时，可能被操作系统分组为多个TCP报文。 前一个报文没有被接收时 后一个无法处理

TCP与UDP的区别

1. 连接
   • TCP 是面向连接的，传输数据前要建立连接
   • UDP 不需要连接，即刻传输数据
2. 服务对象
   • TCP是一对一的两点服务
   • UDP支持多对多
3. 可靠性
   • TCP 是可靠的，数据可以无差错、不丢失、不重复、按序到达
   • UDP 是尽最大努力交付，不保证数据的到达对端
4. 拥塞控制、流量控制
   • TCP 有流量控制和拥塞控制，保证数据传输的安全性
   • UDP 没有，即使网络十分拥堵，也不影响UDP的发送
5. 首部开销
   • TCP 首部开销较长，没有选项时是20个字节，有选项时会增长
   • UDP 首部开销只有固定的8字节
6. 传输方式
   • TCP 是流式传输，没有边界，但保证数据的顺序和可靠
   • UDP 是一个包一个包的发送，一整个包就是数据边界，可能乱序
7. 分片
   • TCP 数据大小大于MSS会在传输层分片，丢包只需要传输该分片
   • UDP 数据大小大于MTU会在IP层分片，丢包需要重传整个UDP包
8. 使用场景
   • TCP 是面向连接的，保证数据可靠交付
     • FTP 文件传输
     • HTTP / HTTPS
     • QQ 聊天
   • UDP 面向无连接，可随时发送数据，加上简单高效
     • 数据包总量较少的通信 DNS SNMP 等
     • 视频、音频等多媒体通信
     • 广播通信

三次握手

• 图片来源于小林Coding
• 为什么是三次握手
  • 主要原因: 避免历史连接
  • 同步双方初始序列号
  • 避免资源浪费
    • 两次握手，服务端只需要收到第一次握手就会建立连接

四次挥手

• 图片来源于小林 Coding
• 为什么是四次挥手
  • 因为被关闭方可能还有数据要处理和发送，等不再发送数据后才发送FIN报文关闭连接
  • 如果一开始就没有数据要发送，那么第二次挥手和第三次挥手可以合并
• TIME_WAIT 状态
  • 为什么等待时间是2MSL
    • MSL是报文最大生存时间，TTL是经过路由跳数
    • 网络中可能存在发送方的数据包，当发送方的数据包被接收方处理后又返回响应，一来一回需要等待2倍的时间
    • 2MSL可以看做是允许报文丢失一次的时间
  • 为什么需要 TIME_WAIT 状态
    • 防止历史链接中的数据被相同四元组错误的接收
      • 让两个方向上的数据包都被丢弃，使原链接上的数据包在网络中自然消失
    • 保证被关闭方能够正常关闭连接
  • TIME_WAIT 过多的危害
    • 占用系统资源
    • 占用端口资源

传输机制

• 图片来源于小林coding
• 重传机制
  • 超时重传
    • 发送数据时，设置定时器，超过指定时间没有收到ACK则重传该数据
    • 超时重传时间设置为RTO，稍大于RTT
    • 每次超时重传时，将下一次超时时间间隔设置为先前值的两倍
  • 快速重传
    • 不以时间驱动，而是以数据为驱动
    • 三次收到同样的ACK就会触发重传
  • SACK
    • 选择性确认，可以将已收到的数据发送给发送方，这样发送方只需要重传丢失数据
  • D-SACK
    • 通知发送方有哪些数据被重复接收
• 滑动窗口
  • 无需等待确认应答，就可以继续发送数据的最大值
  • 发送方的发送窗口
  • 接收方的接收窗口
  • 发送窗口约等于接收窗口，双方不是一成不变的，有传输延迟
• 流量控制
  • 让发送方根据接收方的实际接受能力控制发送的数据量的机制
  • 操作系统缓冲区与滑动窗口
    • 发送窗口和接收窗口的数据都放在操作系统内存缓冲区，操作系统内存缓冲区会被操作系统调整
  • 窗口关闭 (滑动窗口为0)
    • 会阻塞发送方给接收方传递数据
    • 潜在危险： 接收方处理完数据会发送一个窗口非0的ACK报文，但ACK报文丢失不会重传
    • 只要 TCP 连接一方收到对方的零窗口通知，就启动定时器，定时器超时则发送窗口探测报文
  • 糊涂窗口综合症
    • 接收方通知发送方现在只有几个字节的窗口，而发送方直接根据这几个字节的窗口进行发送
    • 但 TCP + IP 包头开销本身就很大，不值得传输，类似于一个50人的大巴车，来了两个人就开车
    • 处理方法
      • 接收方不通知小窗口
      • 发送方不发送小数据
• 拥塞控制
  • 为了避免网络的拥堵恶性循环的放大
  • 拥塞窗口： 根据网络拥塞程度动态变化，在发送方维护
  • 慢启动
    • 发送方每收到一个ACK， CWND 大小加一
    • 但每次发送的包数量也在增加，实际上大约每一个RTT翻倍
    • 慢启动门限 ssthresh 划分慢启动和拥塞避免
  • 拥塞避免
    • 发送方每收到一个 ACK， CWND 大小加 1/CWND
    • 大约每一个RTT增加1
  • 拥塞发生
    • 超时重传
      • ssthresh 阈值降低为 CWND/2
      • CWND 重置为初始值
    • 快速重传
      • ssthresh 阈值设置为 CWND
      • CWND 设置为原来的一半
      • 进入快速恢复算法
  • 快速恢复
    • CWND = sshresh+3
    • 重传丢失的数据包
    • 如果收到重复的ACK 那么CWND加一
    • 如果收到新数据的ACK，那么CWND=ssthresh
• TCP传输绝对可靠吗
  • 常见丢失场景
    • 连接建立时丢包
      • 半连接队列/全连接队列满了会丢包
    • 流量控制丢包
    • 网卡丢包
      • 网络质量差、网线接触不良
      • RingBuffer 过小
      • 网卡性能不足
    • 接收缓冲区丢包
    • 网络丢包
  • TCP丢包会重传
    • 但应用层读取数据时可能因为内存不足或其他原因导致内存闪退
    • 这种丢包可以通过中间服务器保证，每一条消息都有自己的ID，每次查看消息都与该服务器建立通信，检查消息的一致性
  • 总结
    • 数据从发送端到接收端任意一个地方都可能丢包
      • 但平时没事不用关注，因为TCP重传机制保证消息的可靠性
    • 服务异常或者延迟很高时，注意是否为网络丢包，可以通过ping命令查看
    • TCP只保证传输层的消息可靠性，不保证应用层消息的可靠性

TCP保活机制

1. 作用： 避免已建立连接后，有一端突然出现故障
2. 原理： 一个时间段内没有任何连接相关的活动，则每隔一个时间间隔发送一个探测报文，多个探测报文都没有响应，则判断连接死亡
3. 场景
   • 对端正常工作，保活时间重置
   • 对端宕机但重启，产生RST报文重置链接
   • 对端宕机，连接死亡

TCP全连接队列与半连接队列

图片来源于小林Coding

1. 内核维护
2. 半连接队列 也称 SYN 队列
3. 全连接队列 也称 ACCEPT 队列
4. 服务端收到一次握手后，将连接存储到半连接队列，三次握手后，将该半连接移动到全连接队列中，等待进程Accept取用
   • TCP 半连接队列满了后，再收到一次握手就会丢弃
5. SYN泛洪攻击的处理
   1. 调大网卡接收队列
   2. 增大半连接队列
   3. 开启tcp_syncookies
   4. 减少SYN+ACK的重传次数
6. SYNCookies
   • 相当于绕过半连接来建立连接
   • 步骤
     1. SYN队列满了之后，不丢包，而是计算一个cookie值
     2. cookie值放在第二次握手的序列号中，然后回传给客户端
     3. 服务端收到第三次握手时，检测该报文的合法性，合法则放入 Accept 队列中

TCP是面向字节流的

• 如何理解字节流
  • 消息通过TCP进行传输时，会被操作系统拆分成多个TCP报文
  • 不能认为一个用户消息对应一个TCP报文，因此TCP是面向字节流的协议
• 如何解决黏包
  • 固定长度
  • 特殊字符作为边界
  • 自定义消息结构

MTU与MSS

1. MTU: 一个网络包的最大长度
2. MSS: 除去IP和TCP首部后，一个网络包所能容纳的TCP数据最大长度
3. 如果由IP层完成数据包的分片，那么如果一个IP分片丢失，整个IP报文的所有分片都要重传

IP

DNS域名解析

图片来源于小林Coding

1. DNS域名解析: 将域名网址自动转换为具体的 IP 地址
2. 域名用句点(.)来分割，代表不同层次的界限，越靠右层级越高
3. 层级
   1. 根DNS服务器
   2. 顶级域名服务器
   3. 权威域名服务器
4. 域名解析工作流
   1. 查询浏览器缓存、操作系统缓存、hosts文件
   2. 向本地DNS服务器发出DNS请求
   3. 本地DNS服务器向根域名服务器请求
   4. 根域名服务器回复顶级域名服务器地址
   5. 本地DNS服务器向顶级域名服务器发出请求
   6. 顶级域名服务器回复权威域名服务器地址
   7. 本地DNS服务器向权威域名服务器发出请求
   8. 权威域名服务器返回IP地址
   9. 本地DNS服务器返回IP地址

ARP

• 通过ARP协议求得下一条的MAC地址
• 流程
  • 主机广播发送ARP请求
  • 局域网下所有设备收到ARP请求
  • 如果某个设备发现目标IP地址与自己的IP地址一致，那么将自己的MAC地址返回给主机
• RARP 协议
  • 与ARP协议正好相反， 已知MAC地址求IP地址， 将打印机等嵌入式设备连入网络时会用到

ICMP

1. 主要功能
   1. 确认IP包是否成功送达目标地址
   2. 报告发送过程中IP包被废弃的原因
   3. 改善网络设置
2. 类型
   • 查询报文类型
   • 差错报文类型
3. ping命令
   • 查询报文类型的应用
   • 发送者发送ICMP回送请求消息
   • 接收者返回ICMP回送响应消息
   • 
   • 主要就是用到了ICMP中的 ECHO REQUEST(类型8) 和 ECHO REPLY(类型0)
4. traceroute命令
   • 差错类型报文的应用
   • 作用
     • 故意设置特殊的TTL，追踪目的地沿途经过的路由器
       • 故意设置TTL 为1 遇到第一个路由器就返回 ICMP 差错报文数据包
       • 发送UDP包时填入不可能使用的端口号，会返回端口不可达，说明到达了目标主机
     • 故意不设置分片，确定路径的MTU
       • 每次收到差错报文就减少包的大小

127.0.0.1、localhost、0.0.0.0

1. 127.0.0.1 属于回环地址，ping 回环地址不会从网卡发出
2. localhost 是域名地址，但在hosts文件中会被解析为 127.0.0.1
3. 0.0.0.0 表示本机的所有网卡地址
4. ping 127.0.0.1 是绝对能ping通的本地回环地址， ping localhost 失败说明hosts文件出了问题， ping 0.0.0.0 是绝对的无效地址

网络架构

网络分层

图来源于JAVA GUIDE

1. OSI七层模型概念清晰，逻辑完整，但比较复杂且不实用，有些功能重复出现
2. 实现复杂，运行效率低
3. 制定周期长，无法及时进入市场

1. 应用层: 位于传输层之上，提供两个终端设备间信息交换服务，定义了信息交换格式，消息交给下一层传输层来传输
   • HTTP 协议: 超文本传输协议，基于TCP，传输超文本和多媒体内容的协议
   • SMTP 协议: 简单邮件发送协议，基于TCP，用于发送电子邮件的协议
   • POP3/IMAP 协议: 邮件接收协议，基于TCP，负责邮件的接收。
   • FTP 协议: 文件传输协议，基于TCP，用于传输文件，可屏蔽操作系统和文件的存储方式，但是不安全。
   • Telnet 协议: 远程登录协议，基于TCP，通过终端登录到其他服务器，但是不安全。
   • SSH 协议: 安全的网络传输协议，基于TCP，通过加密和认证实现安全的访问和文件传输
   • RTP 协议: 实时传输协议，基于TCP/UDP，提供端到端的实时传输数据
   • DNS 协议: 域名管理系统，基于UDP，用于解决域名和IP地址映射问题
2. 传输层: 负责向两台终端设备进程之间的通信提供通用的数据传输服务
   • TCP 协议: 传输控制协议，提供面向连接的，可靠的数据传输服务
   • UDP 协议: 提供无连接的，尽最大努力交付的数据传输服务
3. 网络层: 负责为分组交换网上的不同主机提供通信服务
   • 负责选择合适的路由，使传输层传下来的分组通过网络层中的路由找到目的主机
   • IP 协议: 网际协议，定义数据包格式、对数据包进行路由和寻址
   • ARP 协议: 地址解析协议，解决网络层地址和链路层地址转换问题
   • ICMP 协议: 互联网控制报文协议，用于传输网络状态和错误消息的协议，用于网络诊断和故障排除
   • NAT 协议: 网络地址转换协议，应用于内部网到外部网的地址转换过程
   • OSPF 协议: 开放式最短路径优先，一种内部网关协议，考虑了链路带宽、延迟等来选择最佳路径
   • RIP 协议: 路由信息协议，一种内部网关协议，基于距离向量算法，使用固定的跳数作为度量标准，选择跳数最少的路径作为最佳路径
   • BGP 协议: 边界网关协议，一种外部网关协议，用来在路由选择域之间交换网络层可达性信息
4. 网络接口层: 数据链路层和物理层的合体，将IP数据包组装成帧，传输透明比特流

杂项

1. 时延

   • 总时延 = 排队时延 + 处理时延 + 传输时延
   • 排队时延：分组在路由器输入队列和输出队列的排队时间
   • 处理时延：主机或路由器收到分组时进行处理的时间
   • 传输时延：主机或路由器书传输数据帧所需的时间
   • 传播时延：电磁波在信道中传播所需的时间

2. CSMA/CD协议

   • 发生碰撞时，采用二进制指数退避算法来确定再次发送时间

3. 网络攻击手段

   • IP 欺骗
     • 伪造某台主机的IP地址
     • 负面作用：伪装成某个正在连接的合法用户，发送RST报文，直接断掉原有连接
     • 缓解措施：入口过滤，检查IP数据包是否具有合法源标头
   • SYN Flood
     • 最原始的DDOS攻击，旨在耗尽可用服务器资源，使服务器无法传输合法流量
     • SYN Flood 利用TCP三次握手机制，控制僵尸主机向服务器发送海量TCP SYN报文，耗尽服务器的半连接队列
     • 缓解措施
       • 扩展半连接队列
       • 回收最开始创建的半连接
       • SYN Cookie
   • UDP Flood
     • 通过ICMP侦测目标服务器的可达端口，再将大量UDP包发送到目标服务器，压倒设备处理和响应能力
     • 缓解措施：限制ICMP报文的响应速率
   • HTTP Flood
     • 利用HTTP请求耗尽可用服务器资源
     • 分为 HTTP GET 攻击 和 HTTP POST 攻击
     • 缓解措施
       • 对发出请求的设备进行机器人测试
       • 防火墙
       • 管理IP信誉数据库等
   • DNS Flood
     • 攻击某个域的DNS服务器，以中断该域的DNS解析
     • 缓解措施：使用一个超大型、高度分布式的DNS系统，以便监测、吸收和阻止攻击流量
   • 中间人攻击
     • 攻击者与通信两端建立单独的连接，并交换所收到的数据，使其两端认为正在私密通话
     • 解决措施：第三方证书
   • 防范DDOS攻击的方法
     • 高防服务器
     • 黑名单
     • DDoS清洗
       • 对用户请求数据进行实时监控，发现异常流量则清洗
     • 内容分发网络CDN加速
       • 将网络流量分配到不同节点中，隐藏网站的真实IP，即使有一个服务器被DDoS攻击也可以将流量分布到不同节点，防止源站崩溃

4. 网络层

   • 
   • 图片来源于CS Notes
   • 热门协议
     • ARP
       • 实现IP地址得到MAC地址
       • 每个主机都有ARP高速缓存，缓存了本局域网内个主机和路由器的IP地址到MAC地址的映射表
     • ICMP
       • 分为差错查询报文和差错报告报文
       • Ping是差错查询报文的应用
       • Traceroute是差错报告报文的应用
     • NAT
       • 将专用网内部的IP地址转换为全球IP地址
       • 反向协议是NAPT
     • 路由选择协议
       • 域内路由协议: RIP OSPF
         • RIP 基于距离向量的路由选择协议，依靠跳数
         • OSPF 基于开放最短路径优先的协议，依靠各链路状态
       • 域间路由协议: BGP
     • ARQ协议
       • 自动重传请求，在不可靠服务上实现可靠传输，一段时间内没有收到ACK则重发
       • 停止等待ARQ
         • 发送一个包就停止发送，等待ACK，一段时间没收到就重发
       • 连续ARQ
         • 发送方维持发送窗口，不需要一直等待一个ACK，采用累计确认，对按序到达的最后一个包进行确认，就表示之前的包都确认了
         • 优点：利用率高，容易实现，即使确认丢失也不必重传
         • 缺点：无法向发送方这反映出接收方已经正确收到的所有包信息。即使某个中间包丢了，后续包也要重传
     • 交换机和路由器的区别
       • 路由器基于IP设计，俗称三层网络网络设备，各个端口都有MAC地址和IP地址
       • 交换机基于以太网设计的，俗称二层网络设备，交换机端口不具有MAC地址

5. 应用层

   • DNS协议
     • 提供了主机名和IP地址之间互相转换的服务
     • 可以使用TCP或UDP进行传输，一般UDP，端口53
   • FTP协议
     • 使用两个TCP连接(控制连接和数据连接)进行传输，使用服务器端口20和21
   • DHCP协议
     • 提供即插即用的联网方式，不需要用户手动配置IP地址等信息
     • 不仅包括IP地址，还包括子网掩码、网关IP地址
     • 工作步骤
       1. 客户端广播 Discover 报文，该报文的目的地址为 255.255.255.255:67，源地址为 0.0.0.0:68，被放入 UDP 中，该报文被广播到同一个子网的所有主机上。
       2. DHCP 服务器收到 Discover 报文之后，发送 Offer 报文给客户端，该报文包含了客户端所需要的信息。因为客户端可能收到多个 DHCP 服务器提供的信息，因此客户端需要进行选择。
       3. 如果客户端选择了某个 DHCP 服务器提供的信息，那么就发送 Request 报文给该 DHCP 服务器。
       4. DHCP 服务器发送 Ack 报文，表示客户端此时可以使用提供给它的信息。
   • 各协议端口占用情况
     • DNS 53 UDP/TCP
     • DHCP 67/68 UDP
     • SNMP 161/162 UDP
     • FTP 20/21 TCP
     • TELNET 23 TCP
     • HTTP 80 TCP
     • SMTP 25 TCP
     • POP3 110 TCP
     • IMAP 143 TCP