TCP/IP模型五层协议

认识协议

约定双方进行的一种约定

协议分层

降低了学习和维护的成本（封装）
灵活的针对这里的某一层协议进行替换

四/五层协议

五层协议的作用

应用层

应用层常见协议

应用层常见协议概览
基于TCP的协议
- HTTP（超文本传输协议）
- SMTP（简单邮件发送协议）
- POP3/IMAP（邮件接收协议）
- FTP（文件传输协议）
- Telnet（远程登录协议）
- SSH（安全的网络传输协议）
基于UDP的协议
- RTP（实时传输协议）
- DNS（域名管理系统）
  - 用于解决域名和IP地址的映射问题
  - 为什么域名解析用UDP协议
    - 因为UDP快。UDP的DNS协议只需要一个请求，一个应答就好了
    - 但是UDP协议传输内容不能超过512字节。不过客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可
  - DNS的工作原理
    - 查询方式
      - 递归查询：主机向本地域名服务器的查询一般都是采用递归查询
        
        主机向本地域名发送查询请求报文，而本地域名服务器不知道该域名对应的IP地址时，本地域名会继续向根域名发送查询请求报文，不是通知主机自己向根域名发送查询请求报文。
      - 迭代查询：本地域名服务器向根域名服务器的查询
        
        本地域名服务器向根域名发出查询请求报文后，根域名不会继续向顶级域名服务器发送查询请求报文，而是通知本地域名服务器向顶级域名发送查询请求报文。
        DNS的缓存位于本地DNS服务器，由于全球的根服务器很少（400+台，13组），且顶级域的数量也在一个可数的范围内，因此本地DNS通常已经缓存了很多TLD DNS服务器，所以在实际查找过程中，无需访问根服务器
    - 工作流程
      - 浏览器输入域名，操作系统会先检查本地的hosts文件是否有这个域名的映射关系，如果有，就先调用这个IP地址映射，完成域名解析
      - 如果hosts文件没有，就去查询本地DNS解析器缓存，如果有缓存记录且缓存记录未过期，就完成地址解析
      - 如果本地DNS解析器缓存中没有，就去查找本地DNS服务器，如果查到，完成解析
      - 如果没有，本地服务器会向根域名服务器发起查询请求，根域名服务器会告诉本地域名服务器去查询哪个顶级域名服务器
      - 本地域名服务器向顶级域名服务器发起查询请求，顶级域名服务器会告诉本地域名服务器去查找哪个权限域名服务器
      - 本地域名服务器向权限域名服务器发起查询请求，权限域名服务器告诉本地域名服务器该域名所对应的IP地址
      - 本地域名服务器告诉主机该域名所对应的IP地址

自定义应用层协议

原因：业务错综复杂，很难有一个通用的协议来满足所有业务需求
怎么自定义
- 结合需求，分析清楚响应要传递哪些信息
- 明确传递的信息以什么样的格式来组织
  - 典型的组织数据的格式
    - 按照文本方式组织
      - json
      - XML
      - 优点：可读性高
      - 缺点：效率低，占用较多的网络带宽
    - 二进制的表示数据的方式
      - protobuffer

传输层

UDP协议

UDP的特点
- 无连接
- 不可靠传输
- 面向数据报
- 全双工
UDP报文
- UDP报头
  - 源端口
    - 端口号使用2个字节，16bit，取值范围是0->65535
  - 目的端口
  - UDP长度
    - 最大只能传输64kb的数据
  - UDP校验和
    - 验证传输的数据是否正确
    - 常见算法
      - CRC
        
        简单粗暴，把数据的每个字节循环网上累加，如果溢出，则舍弃高位
        优点是好算，缺点是校验效果不是特别理想
      - MD5
        
        特点
        
        定长
        冲突概率小
        不可逆
        
        基于这些特点，更多的用处
        
        校验和
        作为计算hash值的方式
        加密
      - SHA1
  - 8个字节，总共有4个部分，每个部分两个字节
- UDP载荷(payload)
  - 放的完整的应用层数据报

TCP协议

TCP的特点
- 有连接
- 可靠传输
  - TCP最核心的部分
  - 保证整体TCP的可靠性
    - 确认应答：传输顺利的情况
    - 超时重传：传输出现问题的情况
    - 三次握手一定程度上也保证了TCP的可靠传输，但是不是起关键作用，是起辅助作用
- 面向字节流
- 全双工
TCP报文
- TCP报头
  - 源端口号（16位）
  - 目的端口号（16位）
  - 序列号（32位）
    - 解决网络包乱序问题
  - 确认应答号（32位）
    - 解决丢包问题
  - 首部长度（4位）
    - 首部长度的单位是4字节
  - 保留（6位）
    - 保证了TCP报文的可扩展性
  - 控制位
    - URG
    - ACK
      - 应答报文
    - PSH
    - RST
      - 用于重置TCP连接，复位报文段
    - SYN
      - 同步报文段，用于发送连接请求
    - FIN
      - 用于发送断开连接请求
  - 窗口大小（12位）
  - 选项（长度可变）
  - 数据
- TCP载荷
TCP内部的工作机制
- 确认应答
  - 实现可靠传输最核心的机制
  - 应答报文
    - ACK=1 说明是应答报文
    - 通过应答报文，可以让发送方清楚的知道是否发送成功
  - 解决网络先发后至问题
    - 序号：任何一条数据都有的
    - 确认序号：只有应答报文才有，收到数据的最后一个字节＋1
- 超时重传
  - 丢包
    - 发送的数据丢了
    - 返回的ACK丢了
  - 超时重传
    - 丢包是概率性事件，重新发送一下数据报，还是有很大概率能成功传输的
    - 超过一定时间，还没有响应的话，就重新传输
  - 如果出现传输的数据重复的情况怎么办？
    - 去重：TCP存在“接受缓存区”，根据序列排序，如果序列重复，则把后面的数据直接丢弃掉
  - 小结：去重和重新排序机制
- 连接管理
  - 建立连接：三次握手
    - 三次握手的意义
      - 1、让通信双方各自建立对对方的“认同”（记录对方的信息）
      - 2、验证通信双方的发送能力和接受能力是否正常
        
        第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的
        第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
        第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
      - 3、在握手的过程中，双方协商一些重要的参数（主要是前两个）
        
        TCP通信过程中，有些数据通信双方要互相同步，此时就需要有这样的交互过程，恰好三次握手可以完成数据的同步
    - 为什么不是四次握手？中间两次交互不合并可以吗？
      - 数据的发送和接受是要封装和分用的，封装分用两次一定比封装分用一次的成本更高，没必要多交互一次
    - 为什么不是两次握手？
      - 三次握手的意义不仅仅要通信双方建立对对方的认同，还要验证双方的发送能力和接受能力是否正常，如果少一次握手，无法确认双方能力都正常
      - 如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源
  - 断开连接：四次挥手
    - 为什么要四次挥手？
      - TCP是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再传送的时候，则发出连接释放通知，对方确认后就可以完全关闭了TCP链接
    - 中间的两次交互为什么不能像三次挥手那样合并在一起呢？
      - 三次握手的交互是在纯内核中完成的（应用程序干预不了），服务器收到SYN后，就会立即发送ACK，同时立即发送SYN
      - 而服务器FIN的发起，是由应用程序控制调用socket的close方法（或者进程退出），而ACK是由内核控制的，收到客户端发送的FIN立即返回ACK
      - 这两者中间就会有一个时间差（是长是短取决于代码），因此不能合并
    - 如果第二次挥手时服务器的ACK没有到达客户端，会怎样？
      - 客户端没有收到ACK确认，会重新发送FIN请求
    - 为什么这里的TIME_WAIT要保持当前的TCP连接状态，不能立即释放呢？
      - 最后一个ACK发出，还没有到达，可能会存在丢包情况
      - 而四次挥手也存在超时重传，站在服务器的角度，无论是ACK丢包还是自己发出的FIN丢包，都视为是FIN丢包，会进行FIN重传。如果立即释放，那将无法对重传的FIN进行ACK响应
        
        TIEM_WAIT等待一段时间后没收到重传的FIN的话，就会视为最后一个ACK没丢，此时就会彻底释放连接
        极端情况下，最后一个ACK丢了，重传的FIN也丢了，此时服务器等待很久也没有收到重传的FIN，最终会释放连接，这种情况无法解决
    - TIME_WAIT具体保持多少时间释放连接呢？
      - 约定一个时间，叫做2MSL
        
        MSL：互联网两个节点之间，数据传输消耗的最大时间
- 发送量控制
  - 滑动窗口
    - 为什么引入
      - 引入可靠性，其实付出了代价：传输效率降低了。所以TCP在保证可靠性的前提下，尽可能地提高传输效率
    - 本质就是降低了确认应答，等待ACK消耗的时间
      - 不等待地批量发送一组数据，然后使用一份时间来等待一组数据的多个ACK
      - 不需要等待就能直接发送的数据的最大量，就叫做“窗口大小”
    - 批量发送了一批数据之后，就开始等待ACK，那什么时候继续往下发送呢？等待什么时候结束呢？
      - 并不是要等所有ACK到了才能发送下一组数据，而是到了一个ACK，就继续往下发送一条
    - 如果出现丢包怎么办
      - ACK丢了
        
        不需要作任何处理，此时要理解确认序号的含义：该序号往前的所有数据都确认到达了。比如2001这个ACK其实包含了1001这个ACK的信息
      - 数据丢了
        
        快速重传：只重传丢失了的数据
        
        如果当前传输数据密集，按照滑动窗口的方式传输，此时按照快速重传处理丢包
        如果当前传输数据稀疏，不按照滑动窗口的方式传输，此时按照超时重传处理丢包
  - 流量控制
    - 一种干预发送的窗口大小的机制
      - 滑动窗口越大，传输效率越高。但是滑动窗口不能无限大
        
        不等ACK，能否保证可靠性
        窗口太大，会消耗大量资源
        发送速度太快，接收方处理不过来，发了也白发
    - 如何衡量接收方的处理能力
      - 看接收方接收缓冲区的剩余大小
        
        每次主机A向主机B发送数据，B就计算一下剩余空间,然后将这个值通过ACK返回给A。A就根据这个值决定接下来的发送速率（窗口大小）
        
        窗口探测报文不携带任何具体的业务数据，只是为了触发ACK查询窗口大小
        
        窗口大小是随着传输过程，动态变化的
        
        窗口大小只有在报文是ACK时才会生效。并且窗口大小不只是64kb，在选项中有个扩展因子可以让窗口更大
  - 拥塞控制
    - 流量控制和拥塞控制共同决定发送方的窗口是多大（取决于二者较小的一个）
      - 流量控制考虑的是接收方的处理能力
      - 拥塞控制描述的是传输过程中，中间节点的处理能力
    - 本质上，是通过实验的方式来逐渐找到一个合适的窗口大小（合适的发送速率）
      - 拥塞窗口不是固定数值，而是一直动态变化的，随着时间推移，逐渐达到一个动态平衡的状态。这样既能解决问题，同时也能随着网络的动态变化而动态变化
- 延时应答
  - 也是提升效率的机制
  - 收到数据后，不是立即返回ACK，而是等会再返回。等待时间里，接收方的应用程序就能把接收缓冲区的数据消费一波，此时剩余空间就更大了
  - 比如这里就是两条返回一个ACK
- 捎带应答
  - 也是提高传输效率的机制（在延时应答的基础上，引入了捎带应答）
  - 本来是不同时机，在延时应答下，可能成为相同时机，就合并发送了
- 面向字节流
  - 可能出现“粘包现象”
    - 由于TCP是面向字节流，所以一次可能读不完一个数据报或者读多个
  - 在应用层约定好应用层协议即可，尤其是明确应用层数据报和应用层数据报之间的边界就好了
    - 约定好分隔符
    - 约定每个报的长度
- 异常情况
  - 进程崩溃
    - 进程没了，对应的PCB就没了，对应的文件描述符表也释放了，相当于socket.close()，此时内核会继续完成四次挥手，仍然是正常断开的流程
  - 主机关机
    - 主机要杀死进程，然后才正式关机，和进程崩溃一样会触发四次握手
  - 主机掉电/网线断开
    - 接收方掉电
      - 等不到ACK会进行超时重传，重传几次还是收不到会尝试重置TCP连接（复位报文段RST），失败后单方面放弃连接
    - 发送方掉电
      - 有保活机制：通过心跳包来确认双方是否处在正常的通信状态
        
        周期性地给发送方发送一条消息，确认下双方是否还在正常工作

TCP和UDP的对比

是否面向连接
- TCP提供面向连接的服务，在传送数据前必须先建立连接，数据传输后要释放连接
- UDP在发送数据之前不需要先建立连接
是否可靠传输
- TCP提供可靠的传输服务，TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制。通过TCP传递的数据，无差错、不丢失、不重复、并且按顺序到达
- 主机收到UDP报文后，不需要给出任何确认，并且不保证数据不丢失/按顺序到达
是否有状态
- TCP传输是有状态的，这个有状态是指TCP会记录自己发送消息的状态，比如消息是否发送了，是否被接收了等等。因此，TCP需要维持复杂的链接状态表
- 和是否可靠传输对应，UDP是无状态服务，简单来说就是不管发出去之后的事情了
传输效率
- TCP进行传输的时候多了连接、确认、重传等机制，所以TCP的传输效率比UDP低很多
传输形式
- TCP是面向字节流的
- UDP是面向数据报的
首部开销
- TCP首部开销（20~60字节）
- UDP首部开销（8字节）
是否提供广播/多播服务
- TCP只支持点对点通信
- UDP支持一对一、一对多、多对一、多对多

网络层

网络层常见协议概览

在这里插入图片描述

IP（网际协议）
ARP（地址解析协议）
- 主要作用：实现从IP地址转换为MAC地址。在每个主机或者路由器中都建有一个ARP缓存表，表中有IP地址及IP地址对应的MAC地址
  - IP地址：互联网协议地址，是IP协议提供的一种统一的地址格式，为互联网的每一个网络和每一台主机分配一个逻辑地址。互联网的每一个资源都有IP地址唯一标识
  - MAC地址：又称物理地址，由网络设备制造商生产时写在硬件内部，不可更改，并且每个以太网设备的MAC地址都是唯一的。特殊地址：FF-FF-FF-FF-FF-FF，该地址表示广播地址
  - ARP表记录了某些其他网络设备的IP地址-MAC地址映射关系，该映射关系以<IP,MAC,TTL>三元组的形式存储。其中，TTL为该映射关系的生存周期，典型值为20mins，超过该时间，该条目将被丢弃
- ARP地址协议
- ARP数据传输
  - 网络层实现的是主机之间的通信，而链路层实现的是链路之间的通信，所以从下图可以看出，在数据传输过程中，IP数据报的源地址(IP1)和目的地址(IP2)是一直不变的，而MAC地址(硬件地址)却一直随着链路的改变而改变
- ARP的工作流程
  - 在局域网内，主机A要向主机B发送IP数据报时，首先会在主机A的ARP缓存表中查找是否有IP地址及其对应的MAC地址，如果有，则将MAC地址写入到MAC帧的首部，并通过局域网将该MAC帧发送到MAC地址所在的主机B
  - 如果主机A的ARP缓存表中没有主机B的IP地址及所对应的MAC地址，主机A会在局域网内广播发送一个ARP请求分组。局域网内的所有主机都会收到这个ARP请求分组
  - 主机B在看到主机A发送的ARP请求分组中有自己的IP地址，会向主机A以单播的方式发送一个带有自己MAC地址的响应分组
  - 主机A收到主机B的ARP响应分组后，会在ARP缓存表中写入主机B的IP地址及其IP地址对应的MAC地址
  - 如果主机A和主机B不在同一个局域网内，即使知道主机B的MAC地址也是不能直接通信的，必须通过路由器转发到主机B的局域网才可以通过主机B的MAC地址找到主机B。并且主机A和主机B已经可以通信的情况下，主机A的ARP缓存表中存的并不是主机B的IP地址及主机B的MAC地址，而是主机B的IP地址及该通信链路上的下一跳路由器的MAC地址。这就是上图中的源IP地址和目的IP地址一直不变，而MAC地址却随着链路的不同而改变
  - 如果主机A和主机B不在同一个局域网，参考上图中的主机H1和主机H2，这时主机H1需要先广播找到路由器R1的MAC地址，再由R1广播找到路由器R2的MAC地址，最后R2广播找到主机H2的MAC地址，建立起通信链路
ICMP（互联网控制协议）
NAT（网络地址转换协议）
OSPF（开放式最短路径优先）
RIP（路由信息协议）
BGP（边际网关协议）