2019-04-04

TCP/IP网络协议

TCP/TP协议
TCP/IP详解

第一天

概述
链路层
IP:网际协议

第二天

ARP
ICMP
PING
Traceroute
IP选路

第三天

UDP
广播和多播
DNS
TFTP

第四天

第五天

第六天

FTP 协议分析
Telnet
HTTP
SMTP/POP3
SSL
SNMP
SIP

TCP-IP协议关系图(tcp-ip-note/TCP-IP协议关系图(A3纸张规格).png)

第一天

1.1 概述分层

mark

链路层：处理与电缆（或其他任何传输媒介）的物理接口细节
网络层处理分组在网络中的活动，e.g 分组选路
运输层为两台主机上的应用程序提供端到端的通讯
应用层处理特定的应用程序细节

mark

1.2 运行FTP的两台主机

mark

大多网络应用程序设计为客户-服务器模式
双方都有对应的一个或者多个协议进行通讯
应用程序通常都是用户进程，而下三层一般在内核执行
应用层关心应用程序的细节，下三层处理通讯细节
分层为应用程序隐藏通讯细节！！！！

1.3 通过路由器链接的两个网络

mark

端系统 end system —PC 服务器
中间系统 intermediate system—路由器
应用层和运输层使用端到端（end to end）协议
网络层提供的是逐跳协议 hop to hop —PC和路由器路由器和PC
网络IP提供的是一种不可靠的服务，只是尽可能快的把分组源节点送到目的节点，但不提供可靠性保障
TCP在不可靠的IP层上提供一个可靠的运输层
互联网的目的之一就是在应用程序中隐藏所有的物理细节

mark

假设电脑–大厦，应用程序–某个房间，房间号–端口号（标识一个应用程序），FTP 客户端和服务器通过FTP协议应用程序到应用程序直接进行通讯， TCP协议主机到主机，端到端。IP协议一个城市的快递公司，链路层–一个媒介，介质到介质。
IP 逐跳以太网逐媒介

mark

1.4 TCP/IP协议簇中不同层次的协议

mark

TCP使用不可靠的IP服务，并提供一种可靠的运输层服务
UDP为应用程序发送和接受数据报，不可靠（查询：DNS53，数据传输：TFTP69，SNMP 161，实时流量：语音视频流）
IP是网络层的主要协议，同时被TCP和UDP使用，还有IPX
ICMP是IP协议的附属协议（ping 一个应用程序，调用ICMP，当IP包丢时，会通过ICMP告诉源，什么问题导致丢失）
ARP ip地址解析为MAC地址

1.5 封装

mark

以太网数据帧的物理特性使其长度必须保持在46-1500字节之间，不够46 补够46，大于1500分片
以太网的帧首部也有一个16bit的帧类型域（IP ARP,ppoe）（以太网协议号），告诉下一个头部是什么
IP 在首部存入一个长度为8bit的数值，称作协议域（ICMP TCP UDP ESP GRE）(IP协议号)
TCP /UDP都用一个16bit的端口号表示不同的应用程序（FTP TELNET HTTP）
发送方叫封装，接收方叫分用
最基本的协议号和端口号
- 以太网协议号
  - IP:0X0800 | ARP:0X0806 | PPPOE 0X8863 0X8864
- IP 协议号
  - ICMP:1 | TCP:6 | UDP:17 | GRE:47 | ESP:50 | AH:51
- 端口号
  - FTP: 20 21 | SSH:22 | Telnet：23 | SMTP:25 | TACACS+:49 | HTTP:80 | HTTPS:443 | IKE: 500

1.6 分用

mark

1.7 端口号

服务器一般通过知名端口号识别（ftp 20 21 telnet 23 目的端口号即为服务器端端口号）
客户端口号又称临时端口号（存在时间很短）
大多数TCP/IP实现给临时端口号分配1024-5000之间的端口号
大于5000 的端口号是为其他服务器预留的

1.8 实现过程

mark

软件是同4.xBSD系统的网络版一起发布的，它的源代码是许多实现的基础

2.1 链路层以太网和IEEE802封装

以太网
- 一般指数字设备公司、英特尔公司、Xerox公司在1982年联合公布的一个标准
- 采用CSMA/CD 的媒体接入方法（Carrier Sense. Multiple Access with Collision Detection）
- 速率10Mb/s，地址18bit
- 之后由IEEE 802.3委员会将其规范化，但两者直接对以太网帧的格式定义有所不同.IEEE802.3所规范的以太网有时又被称为802.3以太网（非IP协议 CDP,VTP）
IEEE 802封装
- 802.3 针对整个CSMA/CD网络
- 802.4 针对令牌总线网络
- 802.5 针对令牌环网络
MAC地址长48bit。任何一个网卡的mac地址唯一
- 根据MAC地址转发

2.2 封装格式

mark

两种帧格式都采用48bit（6字节）的目的地址和和源地址，类型即高速下一个为IP头部
ARP RARP协议对32bit的IP地址和48bit的硬件地址进行映射
802定义的有效长度值与以太网的有效类型值无一相同，这样就可以对两种帧格式进行区分。
目的服务访问点(Destination Service Access Point ,DSAP)和源服务访问点（Source Service Access Point，SSAP）的值都为0xaa，ctrl字段为3.随后的三个字节org code都设置为0。随后的2个字节类型字段和以太网帧格式一样。802.3规定数据部分至少为38字节，而对于以太网至少为46字节。为了保证这一点，不够的要补充pad字节。

mark

2.3 环回口

mark

传给环回地址（一般为127.x.x.x）的任何数据均作为IP输入
传给广播地址或多播地址的数据报复制一份给环回接口，然后送到以太网上。这是因为广播传送和多播传送的定义包含主机本身。广播的数据报根本就没有出去，不是发出去再收回来
任何传给该主机IP地址的数据均送到环回接口

2.4 MTU和路径MTU

mark

以太网和802.3对数据帧的长度都有一个限制，其最大值分别是1500和1492字节。链路层的这个特性称作MTU，最大传输单元。出方向的时候查看MTU，
如果IP层有一个数据报要传送，而且数据的长度比链路层的MTU还大，那么IP层就要分片（fragementation）
点到点的链路层（SLIP /PPP）的MTU并非指的是网络媒体的物理特性，相反，他是一个逻辑限制，目的是为交互使用提供足够快的响应时间
两台通信主机通信路径中的最小MTU，成为路径MTU
路径MTU再两个方向上是不一致的
MTU计算出方向

3.1 网络层和数据链路层的关系

网络层的主要作用是实现终端节点之间的通信。这种终端节点之间的通信也叫点对点通信。（主机到主机，IP到IP）
数据链路层的主要作用是在互联同一种数据链路的节点之间进行包/帧传递，而一旦跨越多种数据链路，就需要借助于网络层。网络层可以跨越不同的数据链路，即使再不同的数据链路上也能实现两端点之间的数据包传输
数据链路层提供直连(网络层面的直连)两个设备之间的通信功能。作为网络层的IP负责在没有直连的两个网络之间进行通信传输
每张票只能在某一限定区间内移动。区间内就是网络上的数据链路。而这个区间的出发点和目的点就是数据链路的源地址和目标地址等首部信息。整个全程的行程表就是网络层
MAC地址标识同一个链路不同计算机的识别码，IP用于在连接到网络中的所有主机中识别出进行通信的目标地址

3.2 IP介绍

IP为TCP/IP协议族中最为核心协议。TCP/UDP/ICMP/IGMP数据都以IP数据报格式传输
IP提供不可靠的无连接的数据报传送服务
不可靠（unreliable）指的是不能保证IP数据报能成功到达目的地。IP仅提供最好的传输服务。如果发生某种错误。IP有一个简单的错误处理算法，丢弃该数据报，然后发送ICMP消息给信源端。任何要求的可靠性必须由上层来提供（tcp/ip）
无连接（connectionless）IP并不维护任何关于后续数据报的状态信息。每个数据报的处理是相互独立的。IP数据报可以不按发送顺序接受。如果一信源向相同的信宿发送两个连续的数据报（A,B），每个数据报都是独立的进行路由选择，可能选择不同的路线，因此B可能再A之前到达。TCP对数据包排序，顺序不对时，缓存。
ifconfig/netstat

3.3 IP首部

3.4 首部字段分析1

版本，4bit组成。表示标识IP首部的版本号，IPV4版本号为4。
首部长度，4bit构成。IP首部大小。单位为4字节（32bit），即一行。对于没有可选项的IP包。首部长度为5。即IP首部长度为20字节。
首部长度最大15 *4字节=60个字节，15行。选项最多40个字节
区分服务位，TOS位
- 8bit构成，表明服务质量。
总长度，表示IP首部和数据部分合起来的总字节数。长16bit。因此IP包最大为65535=2^16字节。
- 目前还不存在能够传输最大长度为65535字节的IP包的数据链路。不过，因为有IP分片处理，从IP的上一层角度看，不论底层采用何种数据链路，都可以认为能够以IP的最大包长传输数据
标识ID，16bit组成。用于分片重组。同一个分片的标识值相同，不同分片标识值不同。通常，每发送一个IP包，它的值也会逐渐增加。此外，如果ID相同，但目标地址、源地址或协议不同的话，也会认为是不同的分片。一个数据报，一个ID，可能分成很多片。
标志，flag
- 3bit构成，表示包被分片的相关信息。
片位移FO–Fragment Offset
- 13bit构成。标识被分片的每一个片段相对于原始数据的位置。第一个分片对应的值为0。由于FO域占13bit。因此最多可以标识8192=2^13个相对位置。单位为8字节。因此最大可表示原始数据8x8192=65536字节的位置。
TTL 生存时间
- 8bit构成。可以中转多少个路由器，每经过一个路由就减一，防止环形路由。
协议
- 8bit构成。表示IP首部的下一个首部属于哪个协议。
- 1 ICMP 6 TCP 17 UDP
首部校验和（Header CheckSum）
- 16bit构成。只校验数据报的首部，不校验数据部分。确保IP数据包不被破坏。
源地址
- 32bit，表示发送端IP地址
目标地址
- 32bit，接收端IP地址
可选项
- 最多40字节
填充Padding
- 再由可选项的情况下，首部长度可能不是32bit的整数倍，为此向该字段填0，调整为32bit的整数倍。
数据
- 存入数据

3.5 IP路由的选择

该例子中所有主机和路由器都使用了默认路由。事实上，大多数主机和一些路由器可以用默认路由来处理任何目的，除非它在本地局域网上
数据报中的目的IP地址始终不发生任何变化（只有使用源路由选项时，目的IP地址地址才可能被修改，很罕见）。所有路由选择决策都是基于这个目的IP地址
每个链路层可能具有不同的数据帧首部，而且链路层的目的地址（如果有的话）始终指向下一站的链路层地址。在例子中，两个以太网封装了含有下一站以太网的链路层首部，但是SLIP链路没有这样做。以太网地址一般通过ARP获得。
源目IP始终保持不表（除非有NAT存在）
每一跳数据链路层地址都随之改变，源为出接口物理地址，目的为路由的下一跳的物理地址

3.6 特殊情况的IP地址

0表示所有bit为0；-1表示所有比特为1；netid,subnetid 和hostid分别表示不为全0 全1的对应字段。子网号栏为空表示该地址没有进行子网划分。
表的头两项为特殊的源地址，中间项为特殊的环回地址，最后四项为广播地址
表中头两项，网络号为0，如主机使用BOOTP协议确定本机IP地址时只能作为初始化过程中的源地址出现。
DHCP UDP包，有源IP地址，为0.0.0.0 目的IP 255.255.255.255
192.168.1.0/24 24 指网络号加子网号的总位数，在没有划分之前ip地址是网络号+主机号，划分子网之后，出现了子网号，子网号是从主机号借的位。子网掩码中前多少号为1
在使用TCP/IP 协议的网络中，主机标识段host ID 为全1 的IP 地址为广播地址，广播的分组传送给host
ID段所涉及的所有计算机。例如，对于10.1.1.0 （255.255.255.0 ）网段，其广播地址为10.1.1.255 （255 即为2
进制的11111111 ），当发出一个目的地址为10.1.1.255 的分组（封包）时，它将被分发给该网段上的所有计算机。
网络地址就是：把IP地址转成二进制和子网掩码进行与运算
广播地址：网络地址的主机位全部变成1
网络地址+1即为第一个主机地址，广播地址-1即为最后一个主机地址
主机的数量=2^二进制位数的主机-2

第二天

1.0 建立TCP连接与ARP的关系

应用接受用户提交的数据，触发TCP建立连接，TCP的第一个SYN报文通过connect函数到达IP层，IP层通过查询路由表：

如果目的IP和自己在同一个网段：
- 当IP层的ARP高速缓存表中存在目的IP对应的MAC地址时，则调用网络接口send函数（参数为IP Packet和目的MAC））将数据提交给网络接口，网络接口完成Ethernet Header + IP + CRC的封装，并发送出去；
- 当IP层的ARP高速缓存表中不存在目的IP对应的MAC地址时，则IP层将TCP的SYN缓存下来，发送ARP广播请求目的IP的MAC，收到ARP应答之后，将应答之中的<IP地址，对应的MAC>对缓存在本地ARP高速缓存表中，然后完成TCP SYN的IP封装，调用网络接口send函数（参数为IP Packet和目的MAC））将数据提交给网络接口，网络接口完成Ethernet Header + IP + CRC的封装，并发送出去；。
如果目的IP地址和自己不在同一个网段，就需要将包发送给默认网关，这需要知道默认网关的MAC地址：
- 当IP层的ARP高速缓存表中存在默认网关对应的MAC地址时，则调用网络接口send函数（参数为IP Packet和默认网关的MAC）将数据提交给网络接口，网络接口完成Ethernet Header + IP + CRC
- 当IP层的ARP高速缓存表中不存在默认网关对应的MAC地址时，则IP层将TCP的SYN缓存下来，发送ARP广播请求默认网关的MAC，收到ARP应答之后，将应答之中的<默认网关地址，对应的MAC>对缓存在本地ARP高速缓存表中，然后完成TCP SYN的IP封装，调用网络接口send函数（参数为IP Packet和默认网关的MAC）将数据提交给网络接口，网络接口完成Ethernet Header + IP + CRC的封装，并发送出去。

1.1 ARP介绍

当一台主机把以太网数据帧发送到位于同一局域网上的另一台主机时，是根据48bit的以太网地址来确认目的接口的。设备驱动程序从不检查IP数据报中的目的IP地址
地址解析为这两种不同的地址形式提供映射。
ARP 为IP地址到对应的硬件地址之间提供动态映射。动态—自动完成
RARP被那些没有磁盘驱动器的系统使用，需要系统管理员进行手动设置
直连时，解析目的主机MAC地址，否则解析下一跳默认网关或者路由的MAC地址
逻辑地址（一般IP），物理地址（MAC/DLCI/全局IP）
仅仅知道目的逻辑地址，不知道物理地址，设备不会向网络发送任何数据帧

1.2逻辑到物理地址的解析协议

以太网 ARP
帧中继（Franme Relay Inverse ARP）
MGRE（NHRP）
这些均支持自动和手动模式
点对点网络无需地址解析协议
- PPP 点对点网络
- 点对点GRE网络
- IPSec VTI网络
- 存储FC网络
- 数据中心FP网络

1.3 ARP高速缓存

ARP高效运行的关键是，每个主机都有一个ARP高速缓存/存放了最近Internet地址到硬件地址之间的映射记录。高速缓存每一项的生存时间一般为20分钟，起始时间从被创建时开始。
PC arp -a arp -d清除
路由器 show arp clear arp

1.4 ARP的分组格式

帧类型0800 IP 0806 ARP 0835 RARP
紧跟着帧类型字段的前4字段指定了最后四个字段的类型和长度
硬件类型以太网 =1
协议类型 IPv4 0x0800
硬件长度 以太网地址长度6 字节
协议长度 IPv4=4字节
操作码 1 request 2 reply 3 RARP请求 4 RARP 应答
大部分的广播包，它们有一个共同特征：二层封装时目的MAC是全f（ffff.ffff.ffff）或三层封装时目的IP是全1（255.255.255.255）。可以这样更方便的记住：目的地址最大的，就是广播。
“问”是通过广播形式实现，”答”是通过单播形式。

1.5 交换机工作原理

1.6 特殊的ARP-ARP代理

R1没有路由能力，不分直连不直连。
有路由能力的直连的直接解析，没有直连的解析网关
一台主机（通常路由器）应答要发送至另一台机器的ARP请求。通过“伪造”其身份，路由器负责将信息包路由到“真实”目的地。代理ARP可以帮助子网中的计算机到达远程子网，而无需配置路由或默认网关。
　代理ARP就是通过使用一个主机(通常为router)，来作为指定的设备使用自己的 MAC 地址来对另一设备的ARP请求作出应答。
为什么需要代理ARP？路由器的重要功能之一就是把局域网的广播包限制在该网内，阻止其扩散，否则会造成网络风暴。

　　ARP请求是个广播包，它询问的对象如果在同一个局域网内，就会收到应答。但是如果询问的对象不在同一个局域网该如何处理？路由器就提供的代理ARP为这个问题提供了解决方案。
　两台主机A和B处于同一网段但不同的广播段时，主机A发送ARP请求主机B的MAC地址时，因为路由器不转发广播包的原因，ARP请求只能到达路由器。如果路由器启用了代理ARP功能，并知道主机B属于它连接的网络，那么路由器就用自己接口的MAC地址代替主机B的MAC地址来对主机A进行ARP应答。主机A接收ARP应答，但并不知道代理ARP的存在
优点：代理ARP能在不影响路由表的情况下添加一个新的Router，使子网对该主机变得透明化。一般代理ARP应该使用在主机没有配置默认网关或没有任何路由策略的网络上。
缺点：从工作工程可以看到，这其实是一种ARP欺骗。而且，通过两个物理网络之间的路由器的代理ARP功能其实互相隐藏了物理网络，这导致无法对网络拓扑进行网络概括。此外，代理ARP增加了使用它的那段网络的ARP流量，主机需要更大的ARP缓存空间，也不会为不使用ARP进行地址解析的网络工作。

1.7 免费ARP

作用1 告诉整个广播域，目前这个IP对应的MAC是什么 （网络设备冷备）
作用2 看看广播内有没有别的主机使用自己的IP，如果使用了，界面上弹出IP冲突（防止地址冲突）
接收方，接收到包后，尽管目的IP不是自己，但会读取源IP和源MAC，并更新自己的ARP缓存

2.1 ICMP介绍

ICMP为IP层的一个组成部分。传递差错报文以及其他需要注意的信息。ICMP报文通常被IP层或者更高层协议（TCP/UDP）使用。一些ICMP报文把差错报文返回给用户进程
一旦丢包，丢包的路由器将差错报文发送源。
ICMP报文在IP数据报内部被传输
ICMP报文前四个字节都相同，IP 首部20字节。
ICMP协议号为1 ICMP:1 | TCP:6 | UDP:17 | GRE:47 | ESP:50 | AH:51
echo request 类型为8 代码为0
echo reply 类型为0 代码为0
校验和：
- 以太网管自己的，IP校验和IP头部，TCP /ICMP 管自己头部和后面所有的
最后两列表示ICMP报文是查询报文还是差错报文
当发送一份ICMP差错报文时，报文始终包含IP的首部和产生ICMP差错报文的IP数据报的前8个字节，这样接受ICMP差错报文的模块就会把它与某个特定的协议（根据IP数据报首部中的协议字段来判断）和用户进程（根据包含在IP数据报前8个字节中的TCP或UDP报文首部中的TCP或UDP端口号来判断）联系起来。

2.2 差错报文

下列情况不会导致产生ICMP差错报文，为了防止过去允许ICMP差错报文对广播分组响应所带来的广播风暴
- ICMP差错报文，但是ICMP查询报文可能会产生差错报文
- 目的地址是广播地址或多播地址的IP数据报
- 作为链路层广播的数据报
- 不是IP分片的第一片，只有第一片才有四层端口号的信息。
- 源地址不是单个主机的数据报。即源地址不能为零地址、环回地址、广播地址、多播地址

2.3 ping介绍

用于进行通信的主机或路由器之间，判断所发送的数据包是否已经成功到达对端的一种消息
ICMP Echo Request —————ICMP Echo Reply
ping 可以确定问题出在哪里，也可以测出到这台主机的往返时间，表明该主机离我们有多远
一台主机的可达性可能不止取决于IP是否可达，还取决于使用何种协议以及端口号，ping不通，不见得一定不通
成发送回显请求的ping程序为客户，而被ping的主机为服务器。大都数的TCP/IP实现都在内核中直接支持ping服务器。这种服务器不是一个用户进程（第六章介绍的两种ICMP查询服务，地址掩码和时间戳请求，也都是直接在内核中进行处理的）
对于其他类型的ICMP查询报文，服务器必须相应标识符和序列号字段。另外，客户发送的选项数据必须回显，假设客户对这些信息都会感兴趣
Unix系统在实现ping程序时是把ICMP报文中的标识符字段置成发送进程的ID号。这样即使在同一台主机上同时运行了多个ping程序实例，ping程序也可以识别出返回的信息。
在windows下，不管开多少个窗口ping的identifier都是相同的，而且每增加一个出去的ping包序列号增加256，能分清楚回来的包吗？？
序号逐个增1

IP选项

2.4 IP记录路由选项

ping程序都提供-R选项，以提供记录路由的功能。使得ping程序在发送出去的IP数据报中设置IP RR选项（在IP可选项部分）（该IP数据报包含ICMP回显请求报文）。这样，每个处理该数据报的路由器都会把它的IP地址放入选项字段中，当数据报到达目的端时，IP地址清单应该复制到ICMP回显应答中，这样返回途中所经过的路由器地址也被加入到清单中。当ping程序收到回显应答时，他就会打印出这份IP地址清单
源端主机生成RR选项，中间路由器对RR选项进行处理，以及把ICMP回显请求中的RR清单复制到ICMP回显应答中，所有这些都为选项功能。幸运的是，现在大多数系统都支持这些选项，只有一些系统不把ICMP请求中的IP清单复制到ICMP应答中。
但是，最大的问题是IP首部中只有有限的空间来存放IP地址。我们从IP首部图中可以看出，IP首部中的首部长度字段只有4bit，因此整个IP首部最长只能包含1532 =60个字节.由于IP首部固定长度20字节，*RR选项用于3个字节，这样只剩下37个字节来存放IP地址清单，也就是说，只能存放9个IP地址**。
记录路由出方向的IP
来来回回都记录
code为一个字节，指明IP选项的类型。对于RR选项来说，值为7。len为RR选项总字节长度，这种情况下为39（尽管可以为RR选项设置比最大长度小的长度，但是ping程序总是提供39字节的选项字段，最多可以记录9个IP，由于IP首部中留给选项的空间有限，它一般情况下设置成最大值）
ptr为指针字段，一个基于1的指针，指向存放下一个IP地址的位置，最小值为4，指向存放第一个IP地址的位置。随着每个IP地址存入清单，ptr的值分别为8，12，16，最大36.当记录下9个IP地址后，ptr值为40，表示清单已满
当路由（多穴）在清单中记录IP地址时，记录出口地址。当原始主机（运行ping的主机）收到带有RR选型的ICMP回显应答时，它也要把它的入口地址放入清单中。

2.5 IP时间戳选项

时间戳选项代码0x44，其他两个字段len ptr与记录路由选项相同。选项总长度（一般36/40）和指向下一个可用空间的指针（5，9，13）
接下来两个字段是4bit值，OF表示溢出字段，FL表示标志字段
时间戳的取值一般为UTC午夜开始计时的毫秒数。与ICMP时间戳请求和应答相似，如果路由器不使用这种格式，他就可以插入任何它使用的时间表示格式。但是必须打开时间戳中的高位以表明为非标准值

3.1 Traceroute VS IP路径记录

不是所有路由都支持记录路由选项，Traceroute不需要路由具备任何特殊的功能
记录路由一般是单向的选项，发送端设置了该选项，那么接收端不得不从收到的IP首部中提取出所有的信息，然后全部返回给发送端。我们看到大多数ping服务器的实现（内核中的ICMP回显应答功能）把收到的RR清单返回，但是这样使得记录下来的IP地址翻了一番（一来一回）。（Traceroute 只需要目的端运行一个UDP模块，其他不需要任何特殊的服务器应用程序）
IP首部留给选项的空间有限，不能存放当前大多数的路径

3.2 Traceroute

可以看到一个IP数据报从一台主机到另一台主机所经过的路由
Traceroute 使用ICMP报文和IP首部中的TTL字段（生存周期）。TTL字段由发送端初始设置一个8bit字段。当前为64。ping程序发送ICMP回显应答，经常把TTL设为最大值255
每个处理数据报的路由器都需要把TTL值减1或者减去数据报在路由器中停留的秒数。由于大多数的路由器转发数据报的时延都小于1s，因此TTL最终成为一个跳站的计数器
当路由器收到一份IP数据报，如果其TTL字段是0或1，则路由器不转发该数据报（接收到这种数据报的目的主机可以将它交给应用程序，这是因为不需要转发该数据报。但是在通常情况下，系统不应接受TTL为0的数据报）。相反，路由器将该数据报丢弃，并给信源机发一份ICMP超时信息。Traceroute程序的关键在于包含这份ICMP信息的IP报文的信源地址是该路由器的IP地址
如何判断是否已经到达目的主机？
- Traceroute发送一份UDP数据报给目的主机，但它选择一个不可能的值作为UDP端口号（大于30000，目的端口号），使目的主机的任何一个应用程序都不可能使用该端口。应为当该数据报到达时，将使目的主机的UDP模块产生一份“端口不可达”的ICMP报文。traceroute要做的就是区分接收到的ICMP报文是超时还是端口不可达，以判断什么时候结束

3.3 IP源站选路选项

由发送者指定路由，有两种方式
- 严格的源站路由选择。发送端指明IP数据报所必须采用的确切路由。如果一个路由器发现源站路由所指定的下一个路由不在其直接链接的网络上，那么它就返回一个“源站路由失败”的ICMP差错报文。
- 宽松的源站路由。发送端指明了一个数据报经过的IP地址清单，但是数据报在清单上指明的任意两个地址之间可以通过其他路由器。
这个格式与记录路由选项格式基本一致。不同之处是，对于源站选路，必须在发送IP数据报前填充IP地址清单。而对于记录路由选项，需要为IP地址清单分配并清空一些空间，并让路由器填充该清单中的各项。同时，对于源站选路，只要为所需要的IP地址数分配空间并进行初始化，通常其数量小于9（预先填好值）。对于记录路由选项而说，必须尽可能分配空间，已达到9个地址。
对于宽松的源站选路而说，code的值为0x83；对于严格的源站选路，其值为0x89，len和ptr字段与路径记录部分所描述的一样。

3.4 IP源站选路的操作机制

源站路由选项的实际称呼为“源站及记录路由”，对于宽松的源站选路和严格的源站选路分别用LSRR 和SSRR表示，这是因为数据报在沿路由发送过程中，对IP地址清单进行了跟新
- a. 发送主机从应用程序接收源站路由清单，将第一个表项去掉（它为数据报的最终目的地址），将剩余的项移到1个项中，如下图，并将原来的目的地址作为清单的最后一项。指针仍然指向清单的第一项（即，指针值为4）
- b.每个处理数据报的路由器都检测其是否为数据报的最终目的地址，如果不是，则正常转发数据报（在这种情况下，必须指明管送源站选路，否则就不能接收到该数据报）
- c. 如果该路由器为最终目的，且指针不太与路径的长度，那么
  - 1. 由ptr所指定的清单中的下一个地址为数据报的最终目的地址
    2. 由外出接口相对应的IP地址取代刚才使用的源地址
    3. 指针+4
Host Requirements RFC指明，TCP客户必须能指明源站选路，同时，TCP服务器必须能够接受源站选路，并且对于该TCP连接的所有保温都能采用反向路由。如果TCP服务器下面接收到一个不同的源站选路，那么新的源站路由将取代旧的源站路由。

3.5 IP选路

选路为IP最重要功能之一
如图为一个路由守护程序daemon，通常是一个用户进程
在unix系统中，大多数普通的守护程序都是路由程序和网关程序
路由表经常被IP访问，但是它被路由守护程序更新的频度却低的很多
当接收到ICMP重定向报文时，路由表也要被更新
netstat显示路由表
route print /netstat -rn
选路原理
- 1 搜索匹配的主机地址
- 2 搜索匹配的网络地址
- 3 搜索默认表项（默认表项一般在路由表中被指定为一个网络表项，其网络号为0）
- IP执行选路机制，而路由守护程序一般提供选路策略

第三天

1.1 UDP介绍

UDP是一个简单的面向数据报的运输层协议：进程的每个输出操作都正好产生一个UDP数据报，并组装成一份待发送的IP数据包
与面向流字符的协议不同，如TCP，TCP的应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么关系。
UDP不提供可靠性，它把应用程序传给IP层的数据发送出去，但是不保证它们能到达目的地
应用程序必须关心IP数据报的长度，如果超过网络的MTU，需要对IP数据报进行分片
UDP是制造IP分片的主要协议
应用程序每有一个数据包，不管数据量大小，UDP就加上UDP头部，IP头部组成一个IP数据报发送
而TCP会选择合适的大小，小的数据包会组装成大的数据包，存在对流的控制
应用
- 查询类DNS
  - 没有TCP三次握手，快
  - 多个DNS同时查询
- 数据传输TFTP
  - 停止等待协议，慢（需应用层确认数据）
  - 适合于无盘工作站
- 语音视频流
  - 支持广播和组播
  - 支持丢包，保障效率

1.2 UDP首部

IP头部协议号ICMP:1 | TCP:6 | UDP:17 | GRE:47 | ESP:50 | AH:51
端口号，表示发送进程和接受进程
TCP端口号与UDP端口号是相互独立的（rsh和syslog=514）
尽管相互独立，如果TCP和UDP同时提供某种指明服务，两个协议通常选择相同的端口号，纯粹为了使用方便，而不是协议本身的要求（DNS 两个都是53端口）
UDP长度指的是UDP首部和UDP数据的字节长度，最小8字节

1.3 UDP校验和

UDP校验和覆盖UDP首部和UDP数据
IP首部检验和覆盖IP首部
UDP检验和可选，TCP校验和必须
IP计算校验和和UDP计算校验和存在不同的地方。首先UDP数据报长度可以为奇数字节，但是校验和算法是把若干个16bit字相加。解决方法是必要时在最后添加填充字节0，只是为了校验和的计算（即，可能增加的填充字节不被传送）
UDP数据报和TCP段都包含一个12字节的伪首部，是为了计算校验和而设置的。伪首部包含IP首部一些字段，其目的是让UDP两次检查数据是否已经正确到达目的地（e.g.IP不接受地址不是本主机的数据报，以及IP不会把应传给另一高层的数据报传给UDP）

1.4 IP分片

IP把MTU（出接口，出去的时候查看MTU）与数据报长度（IP头部+IP数据）比较
如果需要则进行分片。分片可以发生在原始发送端主机上，也可以发生在中间路由器上
把一份IP数据报分片之后，只有到达目的地才进行重新组装(FR fragment)
重新组装由目的端的IP层来完成，其目的是使分片和重新组装过程对传输层（TCP/UDP）是透明的
已经分片过的数据报有可能会再次进行分片
16位标识，初始IP数据报唯一的标识符
CU=0
DF =Do not Fragementation
MF =More Fragementation
IP数据报被分片后，每一片都成为一个分组，具有自己的IP首部，并在选择路由时与其它分组独立。这样，当数据报的这些片到达目的端时有可能会失序，但是在IP首部种有足够的信息让接收端能正常组装这些数据报片
尽管IP分片过程看起来透明，有个缺点：即使只丢失一片数据也要重传整个数据报
IP层本身没有超时重传的机制—由更高层来负责超时和重传（TCP有超时和重传机制，但UDP没有。一些UDP应用程序本身也执行超时和重传）。当来自TCP报文段的某一片丢失后。TCP在超时后会重发整个TCP报文段，该报文段对应于一份数据报。没有办法只重传数据报中一个数据报片。
如果对数据报分片的是中间路由器，而不是起始端系统，那么起始段系统就无法知道数据报是如何被分片的。所以，要避免分片。
分片注意事项
- 分片时，除最后一片外，其它每一片中的数据部分（除IP首部外的其余部分，IP负载）必须为8字节的整数倍
- IP首部被复制到各个分片中，但是端口号在UDP首部（传输层信息），只在第一片中被发现
- IP数据报是指IP层端到端的传输单元（在分片之前和重新组装之后），分组是指在IP层和链路层之间传送的数据单元。一个分组可以是一个完整的IP数据报，也可以是IP数据报的一个分片
- IP数据报数据范围为46-1500，所以垫片=6
路径MTU Path MTU
由于在整个数据包传输过程中，可能在多个节点经历分片。所以如果希望数据报总是不会被分片，就需要用这个路径上最小的MTU来发送数据包。这个在一个路径的某一个方向上最小的MTU就是路径MTU。两个方向上的path mtu可能不一样

1.5 ICMP不可达差错（需要分片）

发生ICMP不可达差错的另一种情况是，当路由器收到一份需要分片的数据报1，而在IP首部又设置了不分片（DF）的标志bit。如果每个程序需要判断到达目的端的路径中最小MTU是多少–称作路径MTU发现机制，那么这个差错就可以被程序利用
如果路由器没有提供这种新的ICMP差错报文，那么下一站的MTU就设为0

1.6 最大UDP数据报长度

IP数据报最大长度为65535字节，由IP首部16bit总长度字段限制
限制1： 应用程序可能会受到其程序接口的限制。socket API提供了一个可供引用程序调用的函数，已设置接受和发送缓存的长度。对于UDP socket，这个长度与应用程序可以读写的最大UDP数据报的长度直接相关。
限制2：TCP/IP内核的实现。可能存在一些实现特性，使ip数据报长度小于65535字节。这个限制与源端和目的端的实现有关
3.2节中提到，要求主机必须能够接收最短为576字节的IP数据报。在许多UDP应用程序设计中，其应用程序数据被限制成512字节或更小，因此比这个限制小。

2.1 广播与多播

三种IP地址：单播地址、广播地址、多播地址
广播和多播进应用于UDP，它们对需将报文传往多个接收者的应用来说重要
TCP是一个面向连接的协议，它意味着分别运行于两主机（由IP地址确定）内的两个进程（由端口号确定）间存在一条连接，一定单播
有时一个主机要向网络上的所有其他主机发送帧，即，广播。通过ARP和RARP可以看到该过程
多播处于单播和广播之间：帧仅传送给属于多播组的多个主机
抓包程序，网卡都是杂合模式
组播在设备驱动程序（链路层）就已经被丢弃了
广播在UDP（传输层）之后被丢弃，消耗PC资源

2.2 广播

受限的广播 255.255.255.255
指向网络的广播 10.255.255.255 192.168.1.255 //netid.255.255.255
- 指向网络的广播地址是主机号为全1的地址。A类网络广播地址为netid.255.255.255，其中netid为A类网络的网络号。
- 一个路由器必须转发指向网络的广播，但它也必须有一个不进行转发的选择。
指向子网的广播 10.1.1.255 10.1.255.255 //跟子网掩码 netid.subnetid.255
- 指向子网的广播地址为主机号为全1且有特定子网号的地址。作为子网直接广播地址的IP地址需要了解子网的掩码。
- 例如，如果路由器收到发往128.1.2.255的数据报，当B类网络128.1的子网掩码为255.255.255.0时，该地址就是指向子网的广播地址；但如果该子网的掩码为255.255.254.0，该地址就不是指向子网的广播地址。
指向所有子网的广播 10.255.255.255// 跟指向子网的广播地址不一样 //netid.255.255
- 指向所有子网的广播也需要了解目的网络的子网掩码，以便与指向网络的广播地址区分开。指向所有子网的广播地址的子网号及主机号为全1。
- 例如，如果目的子网掩码为255.255.255.0，那么IP地址128.1.255.255是一个指向所有子网的广播地址。然而，如果网络没有划分子网，这就是一个指向网络的广播。
主机处理的地址 192.168.255.255 cisco路由支持
路由器支持255.255.255.255 主机不支持（当主机处理）
最常用的是指向子网的广播。受限的广播通常只在系统初始启动时才会用到。

2.3 组播

多播组地址包括为1110的最高4bit和多播组号。通常可表示为点分十进制数，范围从224.0.0.0到239.255.255.255
能够接收发往一个特定多播组地址数据的主机集合称为主机组(host group)。一个主机组可跨越多个网络。主机组中成员可随时加入或离开主机组。主机组中对主机的数量没有限制，同时不属于某一主机组的主机可以向该组发送信息。
一些多播组地址被IANA确定为知名地址。它们也被当作永久主机组，这和TCP及UDP中的熟知端口相似。同样，这些知名多播地址在RFC最新分配数字中列出。注意这些多播地址所代表的组是永久组，而它们的组成员却不是永久的。

例如，224.0.0.1代表“该子网内的所有系统组”，224.0.0.2代表“该子网内的所有路由器组”。多播地址224.0.1.1用作网络时间协议NTP，224.0.0.9用作RIP-2(见10.5节)，224.0.1.2用作SGI公司的dogfight应用。
IANA拥有一个以太网地址块，即高位24 bit为00:00:5e（十六进制表示），这意味着该地址块所拥有的地址范围从00:00:5e:00:00:00到00:00:5e:ff:ff:ff。IANA将其中的一半分配为多播地址。为了指明一个多播地址，任何一个以太网地址的首字节必须是01，这意味着与IP多播相对应的以太网地址范围从01:00:5e:00:00:00到01:00:5e:7f:ff:ff。
这种地址分配将使以太网多播地址中的23bit与IP多播组号对应起来，通过将多播组号中的低位23bit映射到以太网地址中的低位23bit实现，这个过程如图12-3所示。
由于多播组号中的最高5bit在映射过程中被忽略，因此每个以太网多播地址对应的多播组是不唯一的。32个不同的多播组号被映射为一个以太网地址。例如，多播地址224.128.64.32（十六进制e0.80.40.20）和224.0.64.32（十六进制e0.00.40.20）都映射为同一以太网地址01:00:5e:00:40:20。
既然地址映射是不唯一的，设备驱动程序或IP层就必须对数据报进行过滤。因为网卡可能接收到主机不想接收的多播数据帧。
单个物理网络的多播是简单的。多播进程将目的IP地址指明为多播地址，设备驱动程序将它转换为相应的以太网地址，然后把数据发送出去。这些接收进程必须通知它们的IP层，它们想接收的发往给定多播地址的数据报，并且设备驱动程序必须能够接收这些多播帧。这个过程就是“加入一个多播组”（使用“接收进程”复数形式的原因在于对一确定的多播信息，在同一主机或多个主机上存在多个接收者，这也是为什么要首先使用多播的原因）。当一个主机收到多播数据报时，它必须向属于那个多播组的每个进程均传送一个复制。这和单个进程收到单播UDP数据报的UDP不同。使用多播，一个主机上可能存在多个属于同一多播组的进程

3.1 DNS 介绍

Host文件 C：\Windows\System32\drivers\etc\hosts /etc/hosts
用于TCP/IP应用程序的分布式数据库，提供主机名字和IP地址之间的转换以及有关电子邮件的选录信息
分布式是指在Internet上的单个站点不能拥有所有的信息
DNS提供了允许服务器和客户程序相互通信的协议
对DNS的访问是通过一个地址解析器（resolver）来完成的
解析器通常是应用程序的一部分。解析器并不像TCP/IP协议那样是操作系统的内核
操作系统内核中的TCP/IP协议簇对于DNS一点都不知道

3.2 DNS服务器

本章介绍如何使用TCP/IP协议（主要是UDP）与名字服务器通信，不介绍运行名字服务器或有关可选参数的细节
各个域的分层上都有各自的域名服务器
各层域名服务器都了解该层以下分层中所有域名服务器的IP地址。因此它们从根域名服务器开始成树状结构
由于所有域名服务器都了解根域名服务器的地址，所以若从根开始按照顺序追踪，可以访问世界上所有域名服务器

3.3 DNS报文

报文有12字节的首部和4个长度可变的字段组成。
标识字段由客户程序设置并又服务器返回结果。客户程序通过它来确定相应与查询是否匹配
16bit标志字段
- QR 1bit 0表示查询报文，1表示响应报文
- opcode 4bit 0 标准查询 1 反向查询 2 服务器状态请求
- AA 1bit 授权回答该名字服务器是授权于该域的
- TC 1bit 截断的使用UDP时，它表示当应答的总长度超过512字节时，只返回前512个字节。
- RD 1bit 期望递归
- RA 1bit 可用递归
- rcode 4 bit返回码 0没有差错 3 名字差错
- 随后的4个16 bit字段说明最后4个变长字段中包含的条目数。对于查询报文，问题(question)数通常是1，而其他3项则均为0。类似地，对于应答报文，回答数至少是1，剩下的两项可以是0或非0。
查询问题
- 查询名是要查找的名字，它是一个或多个标识符的序列。每个标识符以首字节的计数值来说明随后标识符的字节长度，每个名字以最后字节为0结束，长度为0的标识符是根标识符。计数字节的值必须是0~63的数，因为标识符的最大长度仅为63
资源记录部分
- DNS报文中最后的三个字段，回答字段、授权字段和附加信息字段，均采用一种称为资源记录RR（Resource Record）的相同格式。图14-8显示了资源记录的格式。
- 域名为记录中资源数据对应的名字。格式与查询名字段格式相同
- 类型说明为RR的类型码。值与之前的查询类型值相同。类通常为1，指internet数据。
- 生存时间时是客户程序保留该资源记录的秒数，资源记录通常的生存时间通常2天。

4.1 TFTP简介

Trivial File Transfer Protocol 简单文件传送协议，运行在UDP 端口69，缺乏FTP的高级特性，TFTP只负责将文件写入到远端服务器或者从远端服务器上读取文件。不能够列举、删除或者重命名文件或者目录，并且也不提供用户认证。目前，通常只在局域网内。
传输由client发起，发起一个request来读或者写server上的文件。client可以在request中包含一些可选的参数来和server进行协商。如果server允许这个request，那么文件默认以512字节为一个块或者用协商的大小来发送。为了防止IP分片。每个被传输的块通常被携带在一个IP包中。并且在下一块被传送之前，需要发送确认。如果包小于默认的512字节或者协商的大小，意味着传输要终止
模式字段是一个ASCII码串netascii或octet（可大小写任意组合），同样以0字节结束。netascii表示数据是以成行的ASCII码字符组成，以两个字节—回车字符后跟换行字符（称为CR/LF）作为行结束符。这两个行结束字符在这种格式和本地主机使用的行定界符之间进行转化。octet则将数据看作8bit一组的字节流而不作任何解释。

第四天

1.0 TCP介绍

UDP是一种没有复杂控制，提供面向无连接通信服务的一种协议。将部分控制转移给应用程序去处理（e.g.TFTP），自己只提供作为传输层协议的最基本功能
TCP 对传输、发送、通信进行控制的协议，只有在确认通信对端存在时才会发送数据，从而控制通信流量的浪费，根据TCP这些机制，在IP这种无连接的网络上也能够实现高可靠性的通信。
TCP的可靠性
- 应用数据被分割为TCP认为最为合适发送的数据块
- TCP发出一个字段后，启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段
- 当TCP收到来自TCP连接另一端的数据，将发送一个确认。这个确认不是立即发送，通常延迟几分之一秒，200ms。delayed_ack
- TCP保持首部和数据的校验和
- TCP报文段作为IP数据报来传输，而IP数据报的到达有可能会失序，TCP报文段的到达也可能失序。如果必要，TCP对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。
- TCP提供对流量的控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能容纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出
TCP的字节流
- 两个应用程序通过TCP连接交换8bit字节构成字节流。TCP不在字节流中插入记录标识符。称“字节流服务”。如果一方的应用程序先传10字节，又传20字节，再传50字节，连接的另一方将无法了解发送方每次发送了多少字节。收方可以分四次接收这80个字节，每次接受二十字节。一端将字节流放到TCP连接上，同样的字节流将出现在TCP连接的另一端
- TCP对字节流的内容不做任何解释。TCP不知道传输的数据字节流是二进制数据亦或ASCII字符。对字节流的解释由TCP连接双方的应用层解释

1.1 TCP首部

每个TCP段都包含源端和目的端的端口号，用于寻找发送端和收端应用进程。IP分用。这两个值和IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接。五元组唯一确定session（+protocl）
一个IP地址和一个端口也成为一个插口（socket）插口对（socketpair）
序号用来标识从TCP发端向TCP收端发送的数据字节流，它标识在这个报文段中的第一个数据字节的序号。不会从0或1开始，而是在建立连接时由计算机生成的随机数作为其初始值。？？？？如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。序号为32bit的无符号数，序号到达2的32次方减1后又从0开始。SYN标志消耗了一个序号（FIN标志也占了一个序号）
确认序号是上次已成功收到数据字节序号加1。只有ACK标志位1时确认序号字段才有效。
发送ACK无需占用任何序号，因为32bit的确认序号字段和ACK标志一样，总是TCP首部的一部分。因此，我们看到一旦一个连接建立起来，这个字段总是被设置,ACK标志也总是被设置为1
TCP为应用层提供全双工服务。数据可以在两个方向上独立进行传输，因此，连接的每一端都必须保持每个方向上的传输数据序号。
TCP可以表述为一个没有选择确认或否认的滑动窗口协议，（目前可以选择确认option SACK）。例如如果2-1024字节已经成功收到，下一报文段中包含序号2049-3072的字节，收端不能确认这个新的报文段，所能做的就是发挥一个确认序号为1025的ACK。无法对一个报文进行否认。例如，1024-2048字节的报文检验和出错，TCP接收端能做的就是发回一个确认序号为1024的ACK
数据偏移，或者首部长度，表示TCP所传输的数据部分应该从TCP报的那个位开始计算，4个bit，字节位4字节（32bit）,没有选项字段的话，TCP首部20字节，可设置为5。TCP头部最大15*4=60字节
- URG ，包中有紧急处理的数据
- ACK，为1时，确认应答的字段有效，TCP规定除了最初建立连接时的SYN报之外，该位必须为1
- PSH 为1时，表示将收到的数据立刻传给上传应用协议，否则可先进行缓存
- RST 为1时，TCP连接中出现异常必须强制断开连接。
- SYN 为1时，希望建立连接，并在其序列号的字段进行序列号初始化值的设定
- FIN 为1时，表示今后不会再有数据发送，希望断开连接（单向传输断开）。当通信结束希望断开连接时，通信双方的主机就可以相互交换FIN位置为1的TCP段。每个主机又对对方的fin包进行确认应答后就可以断开连接。主机收到FIN设置为1的TCP段后不必立即回复FIN包，而是可以等到缓存区中所有数据都已成功发送而被自动删除后再发（关闭连接）
窗口大小
- 16bit，流量控制，用于通知从相同的TCP首部确认应答号所指位置开时能够接受的数据大小（8位字节）TCP不允许发送超过此处所表示大小的数据。窗口为0表示可以发送窗口探测，以了解最新窗口大小。但这个数据必须为1个字节。再下一次确认之前，最多发送这么多字节，接收方的流控
校验和
- TCP检验和覆盖TCP首部和TCP数据，TCP校验和必须，而UDP校验和可选，TCP/UDP检验和都要加上12字节的伪首部
紧急指针
- 16bit，只在URG控制位为1时有效。表示本报文段中紧急数据的指针。正确来讲，从数据部分的首位到紧急指针所指示的位置为止都为紧急数据。紧急指针指出了紧急数据的末尾再报文段中的位置
- 如何处理紧急数据属于应用层问题
选项
- 用于提高TCP的传输性能，根据数据偏移（首部长度）进行控制所以其长度最大为字节
- 为32 bit的整数倍
- MSS ，每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志的那个段）中指明这个选项。指明本端所能接收的最大长度的报文段

1.2 连接的管理

TCP提供面向连接的通信传输。UDP是面向无连接的通信协议，不检查对端是否可以通信，直接将UDP包发送出去。TCP与此相反，会在数据通信之前，通过TCP首部发送一个SYN包作为建立连接的请求等待确认回答。如果对端发来确认应答，则认为可以进行数据通信。此外，在通信结束后会进行断开连接的处理（FIN包）
TCP首部用于控制的字段来管理TCP连接，一个链接的建立和断开，正常过程至少来回发送7个包
发送第一个SYN的一端执行主动打开（active open），接收这个SYN并发送下一个SYN的另一端执行被动打开（passive open）
当一端为建立连接而发送它的SYN是，它为连接选择一个初始序号。ISN随时间而变化，且每个连接都有不同的ISN。RFC793指出ISN可看作一个32bit的计数器。每4ms加1。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。
客户通过向服务器发送一个SYN来创建要给主动打开，做欸三次握手的一部分。客户端把这段连接的序号设定为随机数A
服务器端应当为要给合法的SYN回送一个SYN/ACK。ACK的确认码为A+1，SYN/ACK包本身又有一个随即序号B
最后客户端再发送一个ACK。当服务端收到这个ACK后，就完成了握手，并进入连接创建状态。此时报序号被设定为收到的确认号A+1，而相应则为B+1。

1.3连接的断开

SYN 起始序号结束序号最大的报文大小
建立一个连接需要三次握手，而终止一个连接需要四次握手。与TCP的半关闭有关。既然一个TCP连接是全双工的，因此每个方向必须单独的进行关闭。当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向上的连接。当一端收到了FIN，它必需通知应用层另一端终止那个方向的数据传送。发送FIN通常是应用层进行关闭的结果
收到一个FIN只意味着这一方向上没有数据留档。一个TCP连接在收到一个FIN后仍能发送数据。而这对于半关闭的应用来说是可能的，尽管在实际的应用中只有很少的TCP应用程序会这么做
首先进行关闭的一方进行主动关闭，另一方执行被动关闭
还可以发ACK，关闭是关闭数据传输
发送Fin将导致应用程序关闭它们的连接。这些FIN的ACK是TCP软件自动完成的

1.4 连接建立的超时

第一个SYN的重发机制
第二个SYN和第一个差5.8s，第三个和第二个差24s
大多数伯克利系统将建立一个新连接的最长时间限制为75s

1.5 最大报文长度

并不是任何条件下都可协商。当建立一个连接时，每一方都有用于通告它期望接收的MSS选项（MSS选项只能出现在SYN报文中）。如果一方不接受来自另一方的MSS值，默认为536字节
一般，如果没有分段发生，MSS越大越好。报文段越大允许每个报文段传送的数据越多，相对IP和TCP首部有更高的网络利用率。当TCP发送一个SYN时，都能将MSS值设置为外出接口上的MTU长度减去固定的IP首部和TCP首部长度。对于一个以太网，MSS可达1460字节。IEEE802.3封装最大1452字节
如果目的IP地址为“非本地的 nonlocal”，MSS通常默认为536。如果目的IP网络号和子网号和我们的都相同，那么就是本地的。如果网络号相同，子网号不同，那么可能时本地的，也可能不是本地的。大多数TCP实现都提供了一个配置选项，让管理员说明不同的子网是属于本地的还是非本地的。这个选项的设置将确定MSS可以选择尽可能的大或者默认536。

1.6 TCP的半关闭

很少程序使用

1.7 TCP状态变迁图

1.8 2MSL 等待状态

TIME_WAIT状态也称2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL（maximum Segment Lifttime）。它是任何报文段被丢弃前在网络内的最长时间
原因
- 如果服务器再发送FIN后，没有收到客户端的ack。超过重传事件后，服务器重新发送FIN。此时客户端再发送ACK。如果没有TIME_WAIT状态，服务器可能一直收不到ACK，一直保持该会话
- 重传超时时间RTO，RTT往返时间,一般小于30s 1分钟 2分钟
RFC 793指出MSL为两分钟。实际实现为30s，1分钟或2分钟
对一个具体实现所给定的MSL值，处理的原则是：当TCP执行一个TCP主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留时间为2倍的MSL。这样可以让TCP再次发送最后的ACK以防止这个ACK丢弃（另一端超时并重发最后的FIN）
这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能在被使用。这个连接只能在2MSL结束后才能被使用
在连接处于2MSL等待时，任何迟到的报文段将被丢弃。因为处于2MSL等待的、由该插口对定义的连接在这段时间不能被再用，因此当要建立一个有效的连接时，来自该连接的一个较早替身的迟到报文段作为新连接的一部分不可能不被曲解。
客户执行主动关闭并进入TIME_WAIT状态是正常的。服务器通常执行被动关闭，不会进入TIME_WAIT状态。这暗示如果终止一个客户程序并重新启动这个客户程序，则这个新客户程序将不能重用相同的本地端口。
对于服务器，使用熟知端口。如果我们终止一个已经建立连接的服务器程序，并试图立即重新启动这个服务器程序，服务器程序将不能把它的这个熟知端口赋值给它的端点，因为那个端口处于2MSL连接的一部分。

1.9 平静时间

对于来自于某个连接的较早替身的迟到报文段，2MSL等待可防止将它解释称相同插口对的新连接的一部分。但这只有再处于2MSL等待连接中的主机处于正常工作状态时才有效
如果使用处于2MSL等待端口的主机出现故障，它会在MSL秒内重新启动，并立即使用故障前仍处于2MSL的插口对来建立一个新的连接吗？？如果是这样，在故障前从这个连接发出而迟到的报文段会被错误的当作属于重启后新连接的报文段。无论如何选择重启后新连接的初始序号，都会发生这种情况
为了防止这种情况，RFC793指出TCP在重新启动后的MSL秒内不能建立任何连接，这就是平静时间（quite time）
只有极少数的实现版遵守这一规则，因为大多数主机重新启动的时间都比MSL时间长

1.10 FIN_WAIT_2状态

在FIN_WAIT_2状态我们已经发出了FIN，并且另一端也已对它进行确认。除非我们在实行半关闭，否则将等待另一端的应用层意识到它已收到一个文件描述符说明，并向我们发一个FIN来关闭另一个方向的连接。只有当另一端的进程完成这个关闭，我们才会从FIN_WAIT_2状态进入TIME_WAIT状态。
这意味着我们这有可能永远保持这个状态。另一端也将处于CLOSE_WAIT状态，并一直保持这个状态直到应用层决定进行关闭
一般防火墙都有解决半关闭（FIN_WAIT_2）的超时时间设置，如果超时，防火墙会向双方发送RSET(伪装源)来踢掉连接。

1.11复位报文段

TCP首部的RST比特
无论何时一个报文段发往基准的连接（reference connection）出现错误，TCP都会发出一个复位报文段（基准的链接是指有目的IP地址和目的端口号以及源IP地址和源端口号指明的连接）。

1.12 同时打开、关闭

1.13 TCP选项

TLV结构 type+length+value
每个选项的开始是1字节kind字段，说明选项的类型。kind字段为0和1的选项仅占1个字节。其他的选项在kind字节后还有len字节。它说明的长度是指总长度，包括kind字节和len字节。

设置无操作选项的原因在于允许发方填充字段为4字节的倍数。如果我们使用4.4BSD系统进行初始化TCP连接，tcpdump将在初始的SYN上显示下面TCP选项：

<mss 512, nop, wscale 0, nop, nop, timestamp 146647 0>

MSS选项设置为512，后面是NOP，接着是窗口扩大选项。第一个NOP用来将窗口扩大选项填充为4字节的边界。同样，10字节的时间戳选项放在两个NOP后，占12字节，同时使两个4字节的时间戳满足4字节边界。
nop一个空字节 Nop+wscale0 四个字节

2.1 TCP的交互数据流

交互数据流：包的数量多，但多为小包
以Rlogin应用为例
通常每一个交互按键都会产生一个数据分组，这样就会产生四个报文段：
- 来自客户的交互按键
- 来自服务器的按键确认
- 来自服务器的按键回显
- 来自客户的按键回显确认
经受时延的确认
- 通常TCP在接收到数据后并不立即发送ACK，相反，它推迟发送，以便将ACK与需要沿该方向发送的数据一起发送（数据捎带ACK），绝大多数实现采用的时延为200ms，即，TCP将以最大200ms的时延等待是否有数据一起发送
Nagle算法
- 要求一个TCP连接上最多只有一个未被确认的未完成的小分组，在该分组的确认到达前不能发送其他的小分组，这时可以缓冲接下来要发送的数据包，TCP收集这些少量的分组，并在确认到来时以一个分组的方式发出去。该算法的优越性在于它是自适应的：确认到达的越快，数据也就发送的越快。而在希望减少微小分组数目的低速广域网上，则会发送更少的分组
- 注意从左到右待发数据的长度是不同的，分别为1 1 2 1 2 2 3 1 和三个字节。这是因为客户只有收到前一个数据的确认后才发送已经收集的数据。通过Nagle算法，为发送16个字节的数据客户只需要9个报文段，而不是16个。
- nagle算法可以减少网络中微小分组的数量，比如客户端需要依次向服务器发送大小为1,2,3,1,2字节的5个分组
  
  在没有开启nagle算法的情况下，这些小分组会被依次发送（不需要等待上一个小分组的应答，因为没启动nagle），总共发送的报文段（分组）个数为5
  
  当开启nagle算法时，客户端首先发送大小为1字节的第一个分组，随后其它分组到达发送缓冲区，由于上一个分组的应答还没有收到，所以TCP会先缓存新来的这4个小分组，并将其重新分组，组成一个大小为8(2+3+1+2)字节的”较大的”小分组。当第一个小分组的应答收到后，客户端将这个8字节的分组发送。总共发送的报文段（分组）个数为2
- 有时也需要关闭Nagle算法，实时预览的通讯程序而言，e.g.小消息必须无时延的发送
  - 1
    //将套接字描述符设置TCP_NODELAY选项可以禁止nagle算法

增加时延值，减小了小包的数量

2.2 TCP成块的数据流

TFTP使用了停止等待协议。数据发送方在确认下一个数据块之前需要等待接收对已发送数据的确认。本章介绍TCP使用的滑动窗口协议的另一种形式的流量控制方法。该协议允许发送方在停止并等待确认前可以发送多个分组。由于发送方不必每发一个分组就停下来等待确认，该协议可以加速数据的传输。
正常数据流
- 确认机制：
  - 通常使用的“隔一个报文段确认”策略，A发送一个报文给B，A再发送一个报文给B，B发送ACK确认收到的两个报文给A
  - delay_ed ACK, 如果tcp对每个数据包都发送一个ack确认，那么只是一个单独的数据包为了发送一个ack代价比较高，所以tcp会延迟一段时间，如果这段时间内有数据发送到对端，则捎带发送ack，如果在延迟ack定时器触发(200ms)时候，发现ack尚未发送，则立即单独发送
- 我们在线路上看到的分组顺序依赖于许多无法控制的因素：发送方TCP的实现、接收方TCP的实现、接收进程读取数据（依赖于操作系统的调度）和网络的动态性（以太网的冲突和避让），对两个TCP而言，没有一种单一的、正确的方法来交换给定数量的数据
- 通过发送MSS大小，使的慢接收方对快发送方的流量控制
滑动窗口
- 在建立TCP连接的同时，可以确定发送数据包的单位，也称其为最大消息长度（MSS Maximum Segment Size）。最理想的情况是，最大消息长度正好为IP中不会被分片处理的最大数据长度（一般1460-1500-20-20）
- TCP在传送大量数据时，是以MSS的大小将数据进行分割发送。进行重发时也是以MSS为单位
- MSS是在三次握手时，在两端主机之间被计算得出。两端的主机在发送建立连接的请求时，会在TCP首部中写入MSS选项，告诉对方自己的接口能够适应MSS的大小。然后会在两者之间选择一个较小的值投入使用
- 将发送方要发送的字节从1至11标号。接收方通告的窗口成为提出的窗口（offered window），它覆盖了从第4字节到第9字节的区域。表明接收方已经确认了包括第3字节在内的数据，且通告窗口大小为6。表明可以连续发送6个报文无需确认，实际只发送3个报文，未被确认，回顾第17章，知道窗口大小是与确认序号相对应的。发送方计算它的可用窗口，该窗口表明多少数据可以立即传送。当接收方确认数据后，这个滑动窗口不时的向右移动。窗口两个边沿的相对运动增加或减少了窗口的大小
- 称窗口左边向右边靠近时为窗口靠拢。发生在数据被发送和确认时
- 当窗口右边沿向右移动时将允许发送更多的数据，称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了TCP的接收缓存时。
- 当右边沿向左移动，成为窗口收缩。Host Requirements RFC强烈建议不要这么做
- 发送方不必发送一个全窗口大小的数据
- 来自接收方的一个报文段确认数据并把窗口左边沿向右滑动。这是因为窗口的大小是相对于确认序号的
- 正如从报文段7到报文段8中变化的那样，窗口的大小可以减小，但是窗口的右边沿不能向左移动
- 接收方在发送一个ACK前，不必等待窗口被填满。在前面我们看到许多实现每收到两个报文段就会发送一个ACK
- PUSH
  - 发送方使用该标志通知接收方将所收到的数据尽快全部提交给接受进程
  - 数据包括与PUSH一起传送的数据以及接收方TCP已经为接受进程收到的其他数据（已缓存的数据）
- A的slide window 左侧是自己发出，并被对方确认的字节序列号，右侧是左侧+ B通告window size。
慢启动
- TCP三次同步握手建立连接之后，会采用slow start 算法来快速摸到传输路径带宽的峰值。
- 本章所有例子中，发送方一开始便向网络发送多个报文段，直至达到接收方通告的窗口大小为止。当发送方和接收方处于同一个局域网时，这种方式是可以的。但是如果在发送方和接收方之间存在多个路由器和速率较慢的链路时，就有可能出现一些问题。一些中间路由器必须缓存分组，并有可能耗尽存储器的空间，然后发生丢包
- TCP采用慢启动算法来降低一开始就发送过多的数据到网络
- 慢启动为发送方的TCP增加了另一个窗口：拥塞窗口（congestion window）记为cwnd。当与另一个网络的主机建立TCP连接时，拥塞窗口被初始化为1个报文段（即另一端通告的报文段大小）。每收到一个ACK，拥塞窗口就增加一个报文段（cwnd以字节为单位，但是慢启动以报文段为单位进行增加）。发送方取拥塞窗口与通告窗口中的最小值作为发送上限。拥塞窗口是由发送方使用的流量控制，而通告窗口则是接收方使用的流量控制
- 发送方开始时发送一个报文段，然后等待ACK。当收到该ACK时，拥塞窗口从1增加到2，即可以发送两个报文段。当收到这两个的报文段的ACK时，拥塞窗口就增加为4.是一种指数增加的关系
- 在某些点上可能达到了互联网的容量，于是中间路由器开始丢弃分组，发送方检测到丢包，相当于得到通知：发送方的拥塞窗口开的过大，需要进行调整。
- 发送一个分组的时间
  - 通常发送一个分组的时间取决于两个因素：传播时延和发送时延（带宽）
  - 对于一个给定的两个接点之间的通路，传播时延（光速）一般为固定的，而发送时延则取决于分组的大小
  - 在速率较慢的情况下，发送时延起主要作用，而在千兆比特速率下，传播时延起主要作用
成块数据的吞吐量
- 时间19之后，没有收到ack所以最大只能发送4个报文。
- 带宽时延乘积
  - 为了最大限度的利用链路带宽，必须确保发送方源源不断的收到接收方发送的ACK，作为对接收到数据的确认和更新Window size的大小
  - 在开始阶段，通告的window size必须大于等于带宽和往返时延的乘积，才能确保在收到第一个ACK之前，能够一直发送数据流量。因为发送第一个数据报文到收到对应的ACK，时间至少为RTT时间（发一个数据报到收到ACK的时间）
  - 因此传送通道容量为
    - capacity(bit)=bandwidth(b/s)* round-trip time(s) 带宽时延乘积
    - cwnd和 windows size 最小值大于等于 bandwidth* rount-trip-time
- 拥塞
  - 当数据到达一个大的管道（如一个快速局域网）并向一个较小的管道（如一个较慢的广域网）发送时便会发生拥塞。当多个输入流到达一个路由器，而路由器的输出流小于这些输入流的总和时也会发生拥塞。
- 紧急方式
  - TCP提供了紧急方式，它使一端可以高速另一端有些紧急具有某种方式的“紧急数据”已经放置在普通的数据流中。另一端被通知这个紧凑数据已被放置在普通的数据流中，有接收方决定如何处理。可以通过设置TCP首部中的两个字段来发出这种一端到另一端的紧急指针已经被放置在数据流中的通知。URG被置1，并且一个16bit的紧急指针被置为一个正的偏移量，该偏移量与TCP首部中的序号字段相加，得到紧急数据中的最后一个字节的序号。
  - TCP必须通知接受进程，已收到一个紧急数据指针。接受进程读取数据流，并被告知何时碰到紧急数据指针。只要从接收方当前读取位置到紧急数据指针之间由数据存在，就认为应用程序处于紧急模式。在紧急指针通过之后，应用程序便转回到正常方式
  - TCP本身对紧急数据知之甚少，没有办法指明紧急数据从数据流的何处开始。TCP通过连接传送的唯一信息就是紧急指针已经开始（TCP首部中的URG比特）和指向紧急数据最后一个字节的指针，其他事情交给应用程序去处理。
  - 作用
    - Telnet Rlogin 中断键
    - FTP当用户放弃一个文件的传输
    - Telnet和Rlogin从服务器到客户使用紧急方式是因为在这个方向上的数据流很可能要被客户的TCP停止（也即，它通告了一个大小为0的窗口）。但是如果服务器进程进入了紧急方式，尽管它不能够发送任何数据，服务器TCP也会立即发送紧急指针和URG标志。当客户TCP接收到这个通知时就会通知客户进程，于是客户可以从服务器读取其输入、打开窗口并使数据流动。
    - A发送数据至B，B缓冲满，发送window size=0给A，A又要往B发送数据通过紧急模式

2.3 TCP的超时和重传

TCP提供可靠的运输层。使用的方法之一就是确认从另一端收到的数据。但数据和确认都有可能丢失。TCP通过在发送端发送数据时设置一个定时器来解决这种问题。如果当定时器溢出时还没有收到接收方确认，发送端就重传该数据。对任何实现而言，关键之处在于超时和重传的策略，即怎样决定超时间隔和重传的间隔。
对每个连接，TCP管理4个不同的定时器
- 重传定时器用于当发送一个数据报文时，在规定时间内，发送方需要收到另一端发出的接收报文确认。本章详细介绍该定时器，以及一些相关问题，拥塞避免
- 坚持persist定时器使窗口大小信息保持不断流动，即使另一端关闭了其接收窗口 chapter23
- 保活keepalive定时器用于检测一个空闲连接的另一端是否依然保持连接。chapter23
- 2MSL定时器测量一个连接处于TIME_WAIT状态的时间。chapter18.6
- 重传之间的时间间隔为1 3 6 12 24 48 和多个62秒
- 当第一次发送后所设置的超时时间实际上为1.5秒，服务器时间戳最小精度为500ms
- 指数退避 exponential backoff
- 首次分组传输（第6行，24.480秒）与复位信号传输（第19行，566.488秒）之间的时间差为9分钟
- solaris2.2 允许管理者修改这个时间（tcp_ip_abort_interval），且其默认值为2分钟，而不是常用的9分钟
往返时间测量
- TCP超时与重传中最重要的部分就是对一个TCP连接的往返时间RTT的测量。由于网络状况的多变性，RTT时间经常会发生变化，TCP应该跟踪这些变化并相应的改变超时重传时间
- RFC 793 计算方法
  - 使用一个低通滤波器来更新一个被平滑的RTT值，记为O
  - R<- &R+(1-&)M
  - &一个推荐值为0.9的平滑因子。每次进行新测量的时候这个被平滑的RTT将得到更新。
  - 该算法在给定这个随RTT的变化而变化的平滑因子的条件下，RFC推荐的重传超时时间RTO的值应设置为RTO=R@，@为推荐值为2的时延离散因子
- 基于均值和方差来计算RTO
  - 除了被平滑的RTT，还需要跟踪RTT的方差
  - M为当前测出的RTT值，A为被平滑的RTT（均值的估计器），D为被平滑的均值偏差。Err刚得到的测量结果与当前的RTT估计其之差。A和D均被用于计算下一个重传时间。增量g起平均作用，为1/8（0.125）。偏差的增益为h，取值0.25。当RTT变化时，较大的偏差增益使RTO快速上升
  - g h 倍数4均为2的倍数的原因，通过移位实现
  - A为被平滑的RTT，D为被平滑的RTT方差，RTO=A+4D
- 重传多义性问题
  - 在一个分组重传时：假定一个分组被发送。当超时发生时，RTO正进行指数退避，分组以更长的RTO进行重传，然后收到一个确认。那么这个ACK是针对第一个分组还是第二个分组呢，在计算RTT值时考虑
  - Karn 算法，当一个超时和重传发生时，在重传数据的确认最后到达之前，不能更新RTT估计器
  - 一次测量完成，再进行下一次测量
  - 大多数源于伯克利的TCP实现在任何时候对每个连接仅测量一次RTT值。在发送一个报文段时，如果给定连接的定时器已经被使用，则该报文段不被计时
  - 对每个连接而言，除了这个滴答计数器，报文段中数据的起始序号也被记录下来。当收到一个包含这个序号的确认后，该定时器就被关闭。如果ACK到达时数据没有被重传，则被平滑的RTT和被平滑的均值偏差将基于这个新测量进行更新。
- - 发第一个包丢掉时，重传时间6s，第二个也丢掉了，发第三个时重传时间12s
拥塞举例
- 有两种分组丢失的指示：超时和接收到重复的确认
  - 使用超时作为丢包指示，需要一个好的RTT算法
- 重复的ACK,发送端一直发送的数据的起始序列号不是接收方发送ACK的序列号时会发送重复的ACK。收到三个重复的ACK，认为这个包已经丢掉了
- 拥塞避免算法是一种处理丢失分组的方法
- 该算法假定由于分组收到损坏引起的丢失是非常少的（远低于1%），因此分组丢失就意味着在源主机滑动目的主机的某处网络上发生了拥塞
- 拥塞避免算法和慢启动算法是两个目的不同、独立的算法。当拥塞发生时，我们希望降低分组进入网络的传输效率，于是可以调用慢启动来实现这一点。在实际中，这两个算法通常一起实现
- 拥塞避免和慢启动都是发送方使用的流量控制（慢启动允许一方发送连续的未经确认的分组，增加方式采用指数增加，拥塞避免算法允许一方发送连续的未经确认的分组，增加方式采用线性增加），而通告窗口则是接收方进行的流量控制。拥塞避免是发送方对网络可能发生拥塞的估计，而后者则与接收方分配给该连接的接收缓存大小有关。
拥塞避免算法
- 拥塞避免算法和慢启动算法都需要对每个连接维持两个变量：一个拥塞窗口cwnd和一个慢启动门限ssthresh。
- 1. 对一个给定的连接，初始化cwnd为1个报文段，ssthresh为65535个字节
  2. TCP发出未经确认的报文总大小不能超过cwnd和接收方通告窗口的大小
  3. 当拥塞发生时（超时或收到重复确认），ssthresh被设置为当前窗口大小的一半（cwnd和接收方通告窗口的最小值，但至少为2个报文段）。此外，如果是超时引起了拥塞，则cwnd被设置为1个报文段（这就是慢启动），另一种是收到重复确认
  4. 当新的数据被对方确认时，就增加cwnd，但增加的方式依赖于我们是否正在进行慢启动或拥塞避免。如果cwnd小于等于ssthresh则正在进行慢启动，否则正在进行拥塞避免。慢启动一直持续到我们回到当拥塞发生时所处位置一半时才停止（因为我们记录了在步骤3中给我们知道麻烦窗口大小的一半，就是ssthresh），接下来执行的是拥塞避免
- 慢启动算法初始设置cwnd为1个报文段，此后每收到一个确认就加1，这会使窗口在每个RTT时间内按指数方式增长，发送1个报文段，2个，4个
- 拥塞避免算法要求每收到一个确认将cwnd增加1/cwnd。与慢启动指数的增加相比，是一种加性增长。我们希望在一个往返时间内最多为cwnd增加1个报文段（不管在这个RRT中收到了多少了ACK），然而慢启动将根据这个往返时间中所收到的确认的个数增加cwnd。
- 丢包的另一种指示是收到了重复的ACK
- 快速重传算法
  - 如果一连串收到3个或3个以上的重复的ACK，就非常有可能是一个报文段丢失了，于是我们就重传丢失的数据报文段，而无需等待超时定时器溢出
- 快速恢复算法
  - 快速重传后执行的不是慢启动，而是拥塞避免算法
  - 没有执行慢启动原因
    - 收到重复的ACK不仅仅告诉我们一个分组丢失了，还告诉我们一个数据报离开网络顺利的到达接收者。这是由于接收方只有在收到另一个报文段并发现这个报文段不是我当前需要序号的报文才产生重复的ACK，说明有一个报文段已经离开了网络并进入了对方的缓存，也就是说，在收发两端之间仍然有流动的数据，而我们不想执行慢启动来突然减少数据流
    - 慢启动时，cwnd初始化为1，拥塞避免算法时，cwnd初始化为ssthresh
  - 1 当受到第三个重复的ACK时，将ssthresh设置为当前拥塞窗口cwnd的一半。重传丢失的报文段。设置cwnd为ssthresh加上3倍的报文段的大小。（ssthresh本应立即设置为当重传发生时正在起作用的窗口大小的一半，但是在接收到重复ack的过程中允许cwnd保持增加，这是因为每个重复的ack都表示1个报文段已离开了网络，收到3个重复的ack，表示有3个报文离开了网络，并被接收TCP缓存了这几个报文段，正在等待所缺数据的到达）
  - 2 每次收到另一个重复的ack时，cwnd增加1个报文段大小并发送1个分组
  - 3 当下一个确认新数据的ACK到达时，设置cwnd为ssthresh（在第1步中设置的值）。这个ACK应该是在进行重传后的一个往返时间内对步骤1中重传的确认。另外，这个ACK也应该是对丢失的分组和收到的第1个重复的ACK之间的所有中间报文的确认。这一步采用的是拥塞避免，因为当分组丢失时我们将当前的速率减半
按每条路由进行度量
- 新的TCP实现在路由表项中维持许多我们在前面就提到过的指标。当一个TCP连接关闭时，如果已经发送了足够多的数据来获得有意义的统计资料，且目的结点的路由表项不是一个默认的表项，那么下列信息就保存在路由表项中以备下次使用：被平滑的RTT，被平滑的均值偏差以及慢启动门限。所谓“足够多的数据”是指16个窗口的数据，这样就可以得到16个RRT采样
- 当建立一个新的连接时，不论是主动还是被动，如果该连接将要使用的路由表项已经有这些度量的值，则用这些度量来对相应的变量进行初始化。
- B C在同一子网，A有一条明细路由去往B C 所在的子网
ICMP的差错
- 提供information \error message
- TCP能够遇到的常见的ICMP差错就是源站抑制、主机不可达、和网络不可达
- 基于伯克利的实现对这些错误的处理
  - 接收到的源站抑制ICMP差错报文：拥塞窗口cwnd被设置为1个报文段大小，开始慢启动，但是慢启动门限ssthresh没有变化，所以发送窗口将打开直至它或者充分利用收发双方的链路（受窗口大小和往返时间限制）或者发生了拥塞
  - 接收到的主机不可达或网络不可达的ICMP错误都被忽略，因为这两个差错都被认为是短暂现象。这有可能是由于网络发生故障而收敛，需要一定的时间选择替换路径。在收敛过程中可能引起发送这两种ICMP差错中的一种，但是TCP连接并不必被关闭，相反，TCP试图发送引起该差错的数据，尽管最终有可能引起超时
TCP的重新分组
- 当TCP超时并重传时，他并不一定要重传同样的报文段。相反，TCP允许进行重新分组而发送一个较大的报文段，这将有助于提高性能（当然，这个较大的报文段不能够超过接收方声明的MSS）。在协议中这是允许的，因为TCP是使用字节序号而不是报文段编号来进行识别它所要发送的数据和进行确认。

2.4 TCP的坚持定时器

ACK的传输并不可靠，也就是说，TCP不对ACK报文段进行确认，TCP只确认那些含有数据的ACK报文段。如果报文段9丢失怎么办？
问题：如果一个通告窗口更新的确认丢失了，则双方就有可能一直等待下去：接收方等待接收数据（因为它已经向发送方通告了一个非0的窗口），而发送方在等待允许它继续发送数据的窗口更新
解决方法：为防止死锁情况发生，发送方使用一个坚持定时器（persist timer）来周期性的向接收方查询，以便发现窗口是否已经增大。这些从发送方发出的报文段成为窗口探查（window probe）
14 为窗口探查报文
坚持定时器使用了普通的TCP指数退避，在收到一个大小为0的窗口通告后的第1个（报文段14）间隔为4.949秒，下一个（报文段16）间隔为4.996秒，之后间隔1 12 24 48秒和多个60秒
窗口探查包含一个字节的数据（序号为9217）TCP总是允许在关闭连接前发送一个字节的数据。注意。尽管如此，所返回的窗口为0的ACK并不是确认该字节（它们确认了包括9216在内的所有数据）。因此这个字节被持续重传。被持续用来探测对端窗口的变化情况。
糊涂窗口综合征
- 基于窗口的流量控制方案，如TCP使用的，会导致糊涂窗口综合征SWS（Silly Window Syndrome）的状况。如果发生这种情况，则少量的数据将通过连接进行交换，而不是满长度的报文段。导致传输效率低下
- 现象：可发生在两端中的任何一端：接收方可以通告一个小的窗口（而不是一直等到有大的窗口时才通告），而发送方也可以发送少量的数据（而不是等待其他的数据以便发送一个大的报文段）
- 解决方案，可以在任何一端采取措施避免
  - 接收方不通告小窗口。通常的算法是接收方不通告这样的窗口，窗口小于1个报文段（也就是将要接收的MSS），或者窗口小于与接受方缓存空间的一半，不论实际有多少。
  - 发送方避免出现糊涂窗口综合症的措施是仅在满足下列条件时才发送数据
    - 可以发送一个满长度的报文
    - 可以发送至少是接收方通告最大窗口大小一半的报文
    - 没有还未被确认的数据时或者TCP连接上禁止使用Nagle算法
  - 在有尚未被确认数据的情况下，Nagle算法阻止我们发送小的报文段；禁止Nagle算法后，即便有未确认数据包，也可以发送数据包
- 6 窗口探测报文
- 此时MSS=1460 接收方缓冲至少4096
- 11 号大于MSS，1533 因为探测报文占了一个字节

2.5 TCP的保活定时器

如果TCP连接的双方都没有向对方发送数据，则在两个TCP模块之间不交换任何信息，意味着我们可以启动一个客户与服务器建立一个连接，然后离去数小是，数月后，连接依然保持
许多时候一个服务器希望知道客户主机是否关机或者崩溃又重新启动。许多实现提供的保活定时器可以提供这种能力，但是保活定时器并不是TCP规范中的一部分
Host Requirements RFC提供了3个不使用保活定时器的理由
- 在出现短暂差错的情况下，这可能使一个非常好的连接释放掉
- 它们耗费不必要的带宽
- 在按分组计费的情况下会在互联网上花掉更多的钱。并且，许多实现提供了保活定时器
许多人认为，保活定时器应由应用程序完成

3.1 TCP的未来和性能

TCP的一些修改建议，长肥管道，基于事务的TCP（T-TCP）
路径MTU的发现
- 路径MTU单向性
- TCP的路径MTU发现按如下方式进行：在连接建立时，TCP使用输出接口MTU或对端声明的MSS最小值作为起始的报文段大小。路径MTU发现不允许TCP超过对端声明的MSS。如果对端没有指定一个MSS，则默认为536。
- 一旦选定了起始报文的报文段大小，在该连接上的所有被TCP发送的IP数据报都将被设置DF比特。如果某个中间路由器需要对一个设置了DF标志的数据报进行分片。它就丢弃这个数据报，并产生一个ICMP的不能分片的差错。如果收到这个差错，TCP就减少段大小并进行重传。如果路由器产生的是一个较新的该类ICMP差错，则报文携带为下一跳的MTU值。如果是一个较旧的该类ICMP差错，则必须尝试下一个可能的MTU。当由这个ICMP差错引起的重传发生时，拥塞窗口不需要变化，但要启动慢启动。
大分组好还是小分组好
- 常规知识告诉我们较大的分组好，因为发送较少的大分组比发送较多的分组花费更少（假定分组的大小不足以引起分片，否则会引起其他方面的问题）。这些减少的花费和网络（分组首部负荷）、路由器（选路的决定）和主机（协议处理和设备中断）等有关。但并非所有的人都同意该观点
- 时间片个数为分组个数2+跳数3-1=4
- 从R1发送到R4 需消耗21.4*4=85.6秒
- 时间片个数为分组个数16+跳数3-1=18
- 18*2.9=52.2ms
- 每个链路的空闲时间不一样
- 尽管如此，发送还是大的好
长肥管道
- 把一个连接的容量表示为 capacity(b)=bandwidth(b/s) * round-trip time(s) ,也称带宽时延乘积、两端的管道大小
- 当这个乘积变大时，TCP的某些局限性就会暴露出来
- 具有大的带宽时延乘积的网络为长肥网络（long fat network），而另一个运行在LFN上的TCP连接为长肥管道
- 局限性
  - TCP首部中窗口大小为16bit，从而将窗口限制在65535个字节内。（最优窗口=带宽时延乘积）然而现有的网络需要一个更大的窗口来提供最大的吞吐量。后面将介绍窗口扩大选项将解决这个问题
  - 在一个长肥网络LFN内的分组丢失会使吞吐量急剧减少，丢包5%时，吞吐率50%，发生重传
  - 我们在前面看到许多TCP实现对每个窗口的RTT仅进行一次测量。它们并不对每个报文段进行RTT测量。在一个长肥网络LFN上需要更好的RTT测量机制，有一个更好的RTO值。我们将在后面介绍时间戳选项，允许更多的报文段被计时，包括重传
  - TCP对每个字节数据使用一个32bit无符号的序号来进行标识。如果在网络中有一个被延迟一段时间的报文段，它所在的连接已经被释放，而一个新的连接在这两个主机之间又被建立了，怎么才能防止这样的报文段再次出现呢？首先会想起IP首部中的TTL为每个IP段规定了一个生存时间的上限-255跳或255秒，看哪一个上限先到达。我们还定义了最大的报文段生存时间MSL作为一个实现的参数来阻止这种情况的发生。推荐的MSL值为2分钟（给出一个240秒的2MSL），然而许多实现使用的MSL为30秒
- TCP 序号回绕问题
  - 在长肥网络LFN上，TCP的序号会碰到一个不同的问题。由于序号空间有限，在已经传输了4294967296个字节以后序号会被重用。如果一个包含序号N字节数据的报文在网络上被延迟并在连接依然有效时出现，会发生什么情况呢？
  - 在一个以太网上要发送如此多的数据大概需要60分钟，因此不会发生这种情况。但是在带宽增加时，这个时间会减少：一个T3的电话线（45Mb/s）在12分钟内会发生回绕，FDDI（100Mb/s）为5分钟，问题不在于带宽时延乘积，而在于带宽本身
  - 解决方案：使用TCP的时间戳选项的PAWS（Protection Against Wrapped Sequence numbers）保护回绕的序号
- 窗口扩大选项
- 窗口扩大因子
时间戳选项
- 用于更多的数据报参与RTT的计算，以及防止序号回绕
- 时间戳选项使发送方在每个报文段中放置一个时间戳选项。接收方在确认中返回这个数值，从而允许发送方为每一个收到的ACK计算RTT。我们提到过目前许多实现为每一个窗口只计算一个RTT，对于包含8个报文段的窗口而言这是正确的。然而，较大的窗口大小则需要进行更好的RTT计算。
- 发送方在第1个字段中放置一个32bit的值，接收方在应答字段中回显这个数值。包含这个选项的TCP首部长度将从正常的20字节增加到32字节，时间戳是要给单调递增的值。由于接收方只需要回显收到的内容，因此不需要关注时间戳单元是什么。这个选项不需要再两个主机之间进行任何形式的时间同步。
- 工作细节
  - 为了减少任一端所维持的状态数量，对于每个连接只保持一个时间戳的数值。选择何时更新这个数值的算法如下：
  - 1 TCP跟踪下一个ACK中将要发送的时间戳的值（一个名为tsrecent的变量）以及最后发送的ACK中的确认序号（一个名为 lastack）的变量。这个序号就是接收方期待的序号
  - 2 当一个包含有字节号lastack的报文段到达时，则该报文段中的时间戳被保存在tsrecent中
  - 3 无论何时发送一个时间戳选项，tsrecent就作为时间戳回显应答字段被发送，而序号字段被保存在lastack中。
  - 下面我们以一个例子理解timestamp和timestamp echo字段中存放的内容：假设a主机和b主机之间通信，a主机向b主机发送一个报文段，那么：
    
    1）timestamp字段中存放的内容：a主机向b主机发送报文s1，在s1报文中timestamp存储的是a主机发送s1时的内核时刻ta1。
    
    2）timestamp echo字段中存放的内容：b主机收到s1报文并向a主机发送含有确认ack的报文s2，在s2报文中，timestamp为b主机此时的内核时刻tb，而timestamp echo字段为从s1报文中解析出的ta1.
- 我们已经看到接收方TCP不需要对每个包含数据的报文段进行确认，许多实现每两个报文段发送1个ACK。如果接收方发送1个确认了两个报文段的ACK，那么哪一个收到的时间戳应当放入回显应答字段中来发出去呢？
- 如果ACK被接收方延迟，则作为回显值的时间戳值应该对应于最早被确认的报文段。例如，如果两个包含1-1024和1025-2048字节的报文段到达，每一个都带有一个时间戳选项，接收方产生一个ACK 2049来对它们进行确认。此时ACK中的时间戳应该是包含字节1-1024的第1个报文段中的时间戳。这种处理正确。因为发送方在进行重传超时时间的计算时，必须将迟延的ACK也考虑在内
- 尽管时间戳选项能够更好的计算RTT，它还为发送方提供了一种方法，以避免接收到旧的报文段，并认为它们是现在数据的一部分。
- 使用时间戳可以避免这种情况。接收方将时间戳视为序列号的1个32bit的扩展。由于在时间E重新出现的报文段的时间戳为2，这比最近有效的时间戳小（5或6），因此PAWS算法将其丢弃
- PAWS算法不需要再发送方和接收方之间进行任何形式的时间同步。接收方所需要的就是时间戳的值应该单调递增，并且每个窗口至少增加1。
T/TCP为事务用的TCP扩展
- TCP提供的是一种虚电路方式的运输服务。一个连接的生存时间包括三个不同的阶段：建立、数据传输和终止。这种虚电路服务非常适合诸如远程注册和文件传输之类的应用
- 一个事务（transaction）就是符合下面这些特征的一个客户请求及其随后的服务器响应
  - 1 应该避免连接建立和连接终止的开销，在可能的时候发送一个请求分组并接收一个应答分组即可
  - 2 等待时间应该减少到等于RTT和SPT之和。其中RTT(rount -trip-time)为往返时间，而SPT（service processing time）为服务器处理请求的时间
  - 3 服务器应当能够检测出重复的请求，并且当收到一个重复的请求时不重新处理事务（避免重新处理意味着不必再次处理请求，而是返回保存的与该请求对应的应答）
- TCP提供了过多的事务特征，而UDP提供的则不够。通常应用程序使用UDP来构造（避免TCP连接的开销），而许多需要的特征（如动态超时和重传、拥塞避免）被放置在应用层，一遍又一遍的重新设计和实现
- 一个较好的解决方案是提供一个能够提供足够多的事务处理功能的运输层。我们称这样的事务协议为T/TCP。
- T/TCP
  - TCP为处理事务而需要进行的两个改动是避免三次握手和缩短WAIT_TIME状态。T/TCP使用加速打开来避免三次握手
  - 1 它为打开的连接指定一个32bit的连接计数CC（connection count），无论主动打开还是被动打开。一个主机的CC值从一个全局计数器中获得，该计数器每次使用时加1。
  - 2 在两个使用T/TCP的主机之间的每一个报文段都包括一个新的TCP选项 CC
  - 3 一个服务器维护一个缓存，该缓存保留每个主机上一次的CC值，这些值从来自这个主机的一个可接受的SYN报文段中获得
  - 4 当在一个开始的SYN报文中收到一个CC选项时，接收方比较收到的值与缓存该发送方的CC值。如果接收到的CC比缓存的大，则该SYN是新的，报文中的任何数据被传递给接受应用进程（服务器）。这个链接被成为半同步。如果接收的CC比缓存的小，或者接受主机上没有对应的这个客户的缓存的CC，则执行正常的TCP三次握手**
  - 5 为响应一个开始的SYN，带有SYN和ACK的报文段在另一个被称为CCECHO的选项中回显所接收到的CC值
  - 把很多东西融合到一个包中，客户的SYN，请求，
TCP的性能
- TCP的吞吐率限制
  - 不能比最慢的链路运行的更快
  - 不能比最慢的机器的内存运行的更快
  - 不能够比由由接收方提供的窗口处于往返时间所得结果运行的更快（这就是带宽时延乘积公式，使用窗口大小作为带宽时延乘积，就得到带宽值）。
- TCP的最高速率的真正上限是由TCP的窗口大小和光速决定的
- 1Mbps =10^6 bit 链路 1M数据=1024 x1024x8 bit
- time=1024x1024x8/ 10^6
- http://osn.fx.net.nz/LFN/

第六天

6.1 FTP

数据传输的主流协议
两个信道
- 控制信道：认证，罗列目录
- 数据信道：传数据
FTP两个模式
- 实际什么模式由客户端决定。
- Active Mode，第二信道是服务器主动发起的
  - 21 控制信号端口
  - 由服务器给客户端的数据都是由第二信道开始的，第一次建立第二信道是list，第二次建立第二信道是传输数据
  - port a b c d e f 客户端IP地址a.b.c.d 第二信道客户端目的端口号e*256+f
  - 源端口20
  - 发送PORT 172，16，12,101,248,14之后会建立第二信道
  - nc -n -l -p 63502 >result.txt将List结果发送到result.txt
  - 如果要下载文件，需要再次发送port,且再换一个端口号
- Passive Mode，第二信道服务器被动接收的
  - 服务器被动接受，
  - PASV命令询问服务器能否支持Passive Mode，服务器会回一个227命令。
  - 服务器地址a,b,c,e 端口号e*256+f
  - 第二信道双方都是动态端口，更安全。
防火墙或NAT设备对FTP的影响
多信道协议
应用层命令
防火墙做了什么

6.2 Telnet 协议

特别不安全，交互式数据流，ftp成块式数据流
远程登陆服务的标准协议的主要方式。为用户提供了在本地计算机上完成远程主机工作的能力。在终端使用者的电脑上使用telnet程序，用它链接到服务器。终端使用者可以在telent程序中输入命令，这些命令会在服务器上运行，就像直接在服务器的控制台上输入一样。可以在本地就能控制服务器。要开始一个telent会话，必须输入用户名和密码来登陆服务器。telnet是常用的远程控制路由器的方法。
23号端口
交互式TCP数据流的特点
安全问题（替代协议SSH）

6.3 HTTP

HTTP协议（Hypertext Transfer Protocol超文本传输协议）用于从WWW服务器传输超文本到本地浏览器的传送协议，是一个客户端和服务器端请求和应答的标准（TCP）。
HTTP servers are pretty dumb servers 哑服务器
除非主动打招呼，否则不会理你
http (协议)+blog.sina.com.cn (HOST)+ ***.html URI=URL
Cookie ：FTP Telnet 持续性协议，HTTP瞬时协议
- 让整个HTTP协议看似是连续性的，让应用持续提供服务
多连接

6.4 SMTP/POP3

SMTP发邮件 POPE收邮件
SMTP TCP/25
SMTP（simple MailTransfer Protocol 简单邮件传输协议）一组用于由源地址到目的地址传送邮件的规则，由它来控制信件中的中转方式。SMTP属于TCP./IP协议簇，帮助每台计算机在发送或中转信件时找到下一个目的地
SMTP服务器基于DNS中的MX记录来路由电子邮件，MX记录注册域名相关的SMTP中继主机，属于该域的电子邮件都应向该主机发送。若SMTP服务器mail.abc.com收到一封信要发送到collinsctk@qytang.com.cn
- Sendmail请求DNS给出主机qytang.com的MX记录（邮件路由及记录）（如果有CNAME记录(别名)，则需要再解析CNAME，最终得到域名的A记录）
- qytang.com的MX记录如下(nslookup,set q=mx)
  - qytang.com MX preference=5,mail exchanger=mail1.qytang.com
  - qytang.com MX preference=10,mail exchanger=mail2.qytang.com
- Sendmail 请求DNS给出mail1.qytang.com和mail2.qytang.com的A记录（如若有CNAME记录，则需要解析CNMAE最终对应域名的A记录），即IP地址，若返回值为202.100.1.101 和202.100.102
- Sendmail优先投递MX优先级小的服务器，因此与202.100.1.101连接，传送这封给collinsctk@qytang.com的信到202.100.1.101这台服务器的SMTP后台程序
- PTR解析（IP->域名） A解析(域名->IP) MX解析（邮件服务器）
- 主机-CNAME->MX记录->A记录
SMTP协议工作原理
- SMTP在两种情况下工作
  - 电子邮件从客户机传输到服务器
  - 从某一个服务器传输到服务器
- SMTP也是个请求/响应协议，命令和响应都是基于ASCII文本，并以CR/LF（回车换行）结束。响应包括一个表示返回状态的三位数字代码。SMTP在TCP协议25号端口监听持续请求
- 连接和发送过程如下:
  - 建立TCP连接
  - 客户端发送HELO命令以标识发件人自己的身份，然后客户端发送MAIL命令；服务器端正希望以OK作为响应，表明准备接受
  - 客户端发送PCRT命令，以标识该电子邮件的计划接受人，可以有多个RCPT行；服务器端则标识是否愿意为收件人接收邮件。
  - 协商结束，发送邮件，用命令DATA发送
  - 以“.”号表示结束输入内容一起发送过去，结束此次发送，用QUIT命令退出

mark

E:\tools\netcat-win32-1.12>nc smtp.163.com 25
220 163.com Anti-spam GT for Coremail System (163com[20141201])
EHLO smtp.163.com
250-mail
250-PIPELINING
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-coremail 1Uxr2xKj7kG0xkI17xGrU7I0s8FY2U3Uj8Cz28x1UUUUU7Ic2I0Y2UFcv1ZcUCa0xDrUUUUj
250-STARTTLS
250 8BITMIME
AUTH LOGIN
334 dXNlcm5hbWU6
YTEyM2RlNw==
334 UGFzc3dvcmQ6
QWExNTczODUxMzg1MA==
235 Authentication successful
MAIL FROM:<a123de7@163.com>
250 Mail OK
RCPT TO:<a123de7@163.com>
250 Mail OK
DATA
354 End data with <CR><LF>.<CR><LF>
test
test
test
test
mail use nc
TO:a123de7@163.com
From:qweqwe@163.com
SUBJECT:testtest
.
250 Mail OK queued as smtp7,C8CowADXxVp7oLJcq0O1AA--.46051S2 1555210727

POP3,(Post Office Protocol-Version3)即，邮局协议版本3.TCP/IP协议的一员。主要支持使用客户端远程管理在服务器上的电子邮件。提供了SSL加密的POP3成为POP3S
POP协议支持“离线”邮件处理。具体过程为：邮件发送到服务器上，电子邮件客户端调用邮件客户机程序以连接服务器，并下载所有未阅读的电子邮件。这种离线访问模式是一种存储转发服务，将邮件从邮件服务器端发送到个人终端。一旦邮件发送到PC上，邮件服务器上的邮件就会被删除。但目前的POP3邮件服务器大都可以只下载邮件并不删除，也就是改进的POP3协议
TCP/110

6.5 SSL（secure socket layer）

安全套接层用于保障World Wide Web通讯的安全。私有
TLS Transport Layer Security 公有
不依赖于平台和应用程序的协议，用于保障TCP-based运用安全，SSL在TCP层和运用层之间，就像运用层连接到TCP连接的一个插口
PC说我支持很多算法，并发送给服务器，服务器选择一个算法并通知PC。服务器将服务器证书发送给PC（里有公钥），PC用那个算法加密这个公钥得到密钥包并发送给服务器，服务器的私钥去解这个
多个功能可能在一个包中

本文标题:TCP/IP网络协议

文章作者:bliss7

发布时间:2019-04-04, 00:00:00

最后更新:2019-09-02, 08:49:07

原始链接:blissseven.top/2019/04/04/tcp-ip-note/

许可协议: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。

第一天

第二天

第三天

第四天

第五天

第六天

第一天

1.1 概述分层

1.2 运行FTP的两台主机

1.3 通过路由器链接的两个网络

1.4 TCP/IP协议簇中不同层次的协议

1.5 封装

1.6 分用

1.7 端口号

1.8 实现过程

2.1 链路层 以太网和IEEE802封装

2.2 封装格式

2.3 环回口

2.4 MTU和路径MTU

3.1 网络层和数据链路层的关系

3.2 IP介绍

3.3 IP首部

3.4 首部字段分析1

3.5 IP路由的选择

3.6 特殊情况的IP地址

第二天

1.0 建立TCP连接与ARP的关系

1.1 ARP介绍

1.2逻辑到物理地址的解析协议

1.3 ARP高速缓存

1.4 ARP的分组格式

1.5 交换机工作原理

1.6 特殊的ARP-ARP代理

1.7 免费ARP

2.1 ICMP介绍

2.2 差错报文

2.3 ping介绍

IP选项

2.4 IP记录路由选项

2.5 IP时间戳选项

3.1 Traceroute VS IP路径记录

3.2 Traceroute

3.3 IP源站选路选项

3.4 IP源站选路的操作机制

3.5 IP选路

第三天

1.1 UDP介绍

1.2 UDP首部

1.3 UDP校验和

1.4 IP分片

1.5 ICMP不可达差错（需要分片）

1.6 最大UDP数据报长度

2.1 广播与多播

2.2 广播

2.3 组播

3.1 DNS 介绍

3.2 DNS服务器

3.3 DNS报文

4.1 TFTP简介

第四天

1.0 TCP介绍

1.1 TCP首部

1.2 连接的管理

1.3连接的断开

1.4 连接建立的超时

1.5 最大报文长度

1.6 TCP的半关闭

1.7 TCP状态变迁图

1.8 2MSL 等待状态

1.9 平静时间

1.10 FIN_WAIT_2状态

1.11复位报文段

1.12 同时打开、关闭

1.13 TCP选项

2.1 TCP的交互数据流

2.2 TCP成块的数据流

2.3 TCP的超时和重传

2.4 TCP的坚持定时器

2.5 TCP的保活定时器

3.1 TCP的未来和性能

2.1 链路层以太网和IEEE802封装