前些天，有个朋友问我有没有TCP/IP的精简资料，想花个一天大致了解下，于是自己就整理了个文档给他。
后来，想了想，自己玩博客也有段时间了，一直都看别人分享的知识，自己也该贡献下，就形成了这篇博客。
本人主要从事Java Web和Eclipse插件开发，后续的更新主要集中在Java这块，会定期更新一些Java基础知识以及自己工作相关的知识。
TCP/IP 知识总结
1. TCP/IP与OSI分层模型
| OSI模型 | TCP/IP模型 | 功能 |
|---|---|---|
| 应用层、表示层 、会话层 | 应用层 Telnet、FTP、E-mail、SSH、SNMP、HTTP等 | 负责处理特定的应用程序，为用户提供所需的各种服务 |
| 传输层 | 传输层TCP、UDP | 在主机间提供端到端的通信功能 |
| 网络层 | 网络层IP、ICMP、IGMP | 主要解决主机到主机的通信问题 |
| 数据链路层、物理层 | 链路层ARP、RARP | 负责报文收发、IP地址与MAC地址之间转换 |
2. 三层网络结构
3. MAC地址：Media Access Control
网络设备根据目的MAC来判断是否处理接收到以太网帧；
MAC地址是48 bit二进制的地址，前24位为供应商代码，后24为序列号；
分为下面三种类型：
| 类型 | 特点 | 示例 |
|---|---|---|
| 单播地址 | 第一字节最低位为0 | 00-e0-fc-00-00-06 |
| 多播地址 | 第一字节最低位为1 | 01-e0-fc-00-00-06 |
| 广播地址 | 48位全1 | ff-ff-ff-ff-ff-ff |
4. 以太网两种帧格式
5. PPP：广域网协议，点对点协议
负责在同步和异步电路上提供点对点的数据传输；
组成：链路控制协议LCP，网络控制协议LNP，认证协议；
主要功能：
- 具有动态分配IP地址的能力，允许在连接时刻协商IP地址
- 支持多种网络协议，比如TCP/IP、NWLINK等
- 具有错误检测以及纠错能力，支持数据压缩
- 具有身份认证功能， PAP验证和CHAP验证两种，也支持计费
- 用于多种类型的物理介质上，包括串口线、电话线、移动电话和光纤
- 支持多链路捆绑
6. IP协议
IP报文头
- 头部长度：通常20字节，有选项时更长，总共不超过60字节
- IP数据报长度：65535字节
- 版本号：表示IP协议版本号。目前的版本号是4
- 报文头长度：表示报文头长度，以4 Byte为单位
- 总长：以Byte单位表示整个IP数据报长度，包括报文头及携带的数据
- 标识、标志、片偏移：这3个字段与报文分片有关；
IP协议的两个特点 - 无连接：IP并不维护任何关于后续数据报的状态信息
- 不可靠：不能保证IP数据报成功到达目的地，若发生错误，丢弃该数据报，然后发送ICMP消息报给信源端；
IP地址分类
| 类型 | 头位 | 后续位 | 范围 |
|---|---|---|---|
| A类 | 0 | 7位网络号 24位主机号 | 0.0.0.0到127.255.255.255 |
| B类 | 10 | 14位网络号 16位主机号 | 128.0.0.0到191.255.255.255 |
| C类 | 110 | 21位网络号 8位主机号 | 192.0.0.0到223.255.255.255 |
| D类 | 1110 | 28位多播地址 | 224.0.0.0到239.255.255.255 |
| E类 | 11110 | 27位主机号 | 240.0.0.0到247.255.255.255 |
7. ARP
为IP地址到对应的硬件地址提供动态映射
其报文格式如下：
- 前两个字段是以太网帧头的目的地址和源地址
- 帧类型对于ARP取值0x0806，RARP取值0x8035
- 硬件类型取值1标识以太网类型
- 协议类型针对IP协议取值0X0800
- 硬件地址长度和协议地址长度分别标识以太网地址长度6和IP地址长度4
- OP操作类型：1－ARP请求，2－ARP应答，3－RARP请求，4－RARP应答
- 后续的四个字段与以太网帧头有重复的字段，在ARP请求中目的以太网地址取值全0，其他三个字段都有相应取值；
原理
- 每一个主机都有一个ARP高速缓存（ARP cache），即IP地址到物理地址的映射表，包含IP地址到物理地址的映射关系
- 当主机A欲向本局域网上的主机B发送一个IP数据报时，就先在其ARP高速缓存中查看有无主机B的IP地址。如有，就可查出其对应的物理地址，然后将该数据报发往此物理地址
- 若在ARP cache中没有相应的地址映射记录，主机A首先发送广播地址的ARP请求，在本网段的所有主机都能收到该ARP请求（OP=1），ARP请求中的目的以太网地址取值全0，目的IP地址为主机B的IP地址
- 在本网段的所有主机都能收到该ARP请求，主机B见到ARP分组中包含自己的IP地址，予以ARP响应（OP=2），将自己的地址信息填入发送端地址字段；主机B可以主机A的地址映射关系添加到自己的ARP cache中
- 主机A收到ARP响应后，将主机B的地址映射关系添加到ARP cache中
免费ARP
主机发送目的IP地址为自己的IP地址的ARP请求的特性：
- 免费ARP可用于检测本网段上是否有其他主机在使用与本机相同的IP地址；
- 通过免费ARP的发送可使得本网段的其他主机对ARP表进行相应更新。
8. ICMP
Internet控制报文协议：负责传递差错，查询报文等；
ICMP差错报文包含产生差错的IP报文首部和数据部分的前8个字节；
触发重定向报文两个条件：
- 路由器B的接口e0/1和主机A同属一个网段
- 报文的下一跳转发地址和报文的源地址在同一网段上；
9. Traceroute命令
用于检测IP数据包到目的端所经过的路径，可以标识出路径中各个设备的IP地址
Traceroute使用了icmp报文和IP报文中的TTL值实现路径的检测；
Traceroute的关键是到达目的主机的路径中的每个路由器会接收到TTL值为1的UDP报文，会回复ICMP超时报文，该报文中包含了路由器的IP地址，因此记录了达到目的主机的路径，实现步骤如下：
- 源端首先发送一个TTL为1的报文，第1跳设备收到后，丢弃该报文，回复ICMP超时报文，源端收到报文后，记录第1跳设备地址
- 源端发送TTL为2的报文，第2跳设备收到后，该报文的TTL也变成了1，同样丢弃该报文，回复ICMP超时报文，源端收到报文后，记录第2跳设备地址
- 以此类推，直到到达目的地址。因为已经到达目的端，不会发送ICMP超时报文，此时因为目的地址采用的是ICMP端口不可达报文，因为UDP报文的目的端口号通常选择超过30000的，应用程序不使用的端口
10. 单播、广播和组播
单播：通常一个报文仅发送给一个目的主机，称为单播报文
广播：一个主机要向网络上的所有其他主机发送报文，称为广播
- 广播报文目的IP地址的主机部分全为1，如B类地址172.16.0.0/16，其广播地址为172.16.255.255
- 广播报文的MAC地址，在以太网中，48位全为1，即FF-FF-FF-FF-FF-FF
组播：一个主机需要向特定组中的主机发送报文，称为组播
- 组播报文的目的IP地址范围是224.0.0.0~239.255.255.255，源IP地址仍然是发送方的单播IP地址
- 组播MAC地址的标识是：最高字节的最后一位是1； xxxxxxx1.xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
- 01-00-5e开头的MAC用于组网IPv4到组播MAC的映射
- 01-80-c2开头的MAC一般用于二层协议
11. TCP和UDP
TCP提供可靠的端到端传输服务，UDP简单地将数据报从一端传输至另一端，传输的可靠性由应用层保证
TCP自身提供的可靠性机制
- 报文确认（ACK）：对于接收端来讲的是需要请求传输的数据，表示之前的数据已经收到和期望下次传输的数据
- 超时重传：普通重传和快速重传
- 端到端校验：校验和
- 数据分割：
- 重新排序：
- 流量控制：滑动窗口和拥塞窗口
- 重复丢弃：对于接收端
三次、四次握手
这是面试重点中的重点
连接时是三次握手，终止连接时是四次握手
网上讲三次、四次握手的实在太多了，这里懒得详细写，自己可以百度看
半连接/关闭
-
半连接：当TCP连接的一方异常终止连接未给对方发送FIN报文，而另一方却不知道，这样的TCP连接成为半打开。例如客户机telnet到服务器，然后突然关闭主机，就会产生半打开的现象；当第二天再开机启动一个新的telnet客户程序时，服务器上就会启动一个新的服务器进程，于是导致服务器中产生许多半打开的TCP连接——此问题需要依靠TCP的keepalive选项功能检测对方是否已经消失的机制来解决
-
半关闭：TCP提供了连接的一方在结束它的发送任务后还能接续接收对方数据的能力，即它完成了数据发送，于是发送一个FIN给对方，但它还想接收来自另一端的数据，直到收到来自对方的FIN消息
滑动窗口机制
滑动窗口机制允许发送方在等待确认前可以连续发送多个分组，由于发送方不必每发送一个数据就等待确认，因此加速了数据的传输。窗口大小就是指无需等待确认应答而可以继续发送数据的最大值，范围实际上是接收方能够接收的序号范围，ACK告知了起始序号，win大小告知了窗口大小。
接收方通告的窗口大小称为提供的窗口（Offered Window），说明自己此时可以接收的数据大小；发送方可使用的窗口大小称为可用窗口，值=“提供的窗口-已发送而未确认的数据字节数”，意即发送方此时可以继续立即发送的数据大小。
三个术语：
- 窗口合拢：窗口左沿往右沿靠近，此时部分数据被发送并被确认
- 窗口张开：窗口右沿往右移动，此时接收端读取并确认了数据，释放了接收缓存
- 窗口收缩：窗口右沿往左移动，RFC强烈建议不使用
以上述例子可以总结如下几点：
（a）发送方不必发送一个全窗口大小的数据
（b）来自接收方的确认导致窗口向右滑动
（c）窗口大小可以减少，但是右边不能左移
（d）接收方发送确认前不必等待窗口被填满
常见的TCP应用
| 类型 | 中文名 | 应用 | 端口号 |
|---|---|---|---|
| DNS | 域名服务 | TCP，UDP | 53 |
| FTP-data | 文件传输协议－数据 | TCP | 20 |
| FTP | 文件传输协议 | TCP | 21 |
| Telnet | TCP | 23 | |
| NTP | 简单时间协议 | TCP，UDP | 123 |
| HTTP | 超文本传输协议 | TCP | 80 |
12. DHCP
Dynamic Host Configuration Protocol，动态主机配置协议，用来为网络设备动态地分配IP地址等网络配置参数
DHCP CLIENT将采用知名端口号68，DHCP SERVER采用知名端口号67
IP地址分配策略
- 手工分配地址：由管理员为少数特定客户端静态绑定固定的IP地址。通过DHCP将配置的固定IP地址发给客户端。
- 自动分配地址：DHCP为客户端分配租期为无限长的IP地址。
- 动态分配地址：DHCP为客户端分配具有一定有效期限的IP地址，到达使用期限后，客户端需要重新申请地址
地址获取过程
-
发现阶段，即DHCP客户端寻找DHCP服务器的阶段。
客户端以广播方式发送DHCP-DISCOVER报文，源IP地址为0.0.0.0,目的IP地址为255.255.255.255，且上层协议为UDP协议，源端口号68，目的端口为67 -
提供阶段，即DHCP服务器提供IP地址的阶段。
DHCP服务器接收到客户端的DHCP-DISCOVER报文后，根据IP地址分配的优先次序选出一个IP地址，与其他参数一起通过DHCP-OFFER报文发送给客户端（一般是广播报文，也可是单播报文，看标志位） -
选择阶段，即DHCP客户端选择IP地址的阶段。
如果有多台DHCP服务器向该客户端发来DHCP-OFFER报文，客户端只接受第一个收到的DHCP-OFFER报文，然后以广播方式发送DHCP-REQUEST报文，该报文中包含DHCP服务器在DHCP-OFFER报文中分配的IP地址。 -
确认阶段，即DHCP服务器确认IP地址的阶段。
DHCP服务器收到DHCP客户端发来的DHCP-REQUEST报文后，只有DHCP客户端选择的服务器会进行如下操作：如果确认将地址分配给该客户端，则返回DHCP-ACK报文；否则返回DHCP-NAK报文，表明地址不能分配给该客户端。（可以广播，也可以单播）
如果在租约的一半时间进行的续约操作失败，DHCP客户端会在租约期限达到7/8时，广播发送DHCP-REQUEST报文进行续约。
13. 路由
路由信息是指导报文发送的路径信息
来源
- 链路层协议发现的路由（Direct）
- 手工配置的静态路由（Static）
- 动态路由协议发现的路由（RIP、OSPF 、ISIS 、BGP……）
最长匹配原则：所有匹配路由中，选择掩码最长的
出现等价路由时候的转发
- 逐流转发：通过IP报文的5元组（源和目的地址、源和目的端口号，协议号）的哈希值选择出接口（如以等价下一跳的个数为模取余），这样同一条流只选择同一个出口，防止报文乱序
- 逐包转发：相同目的网段的报文，依次轮流使用不同的下一跳转发