概述

分层

  • 链路层：处理与电缆（或其他任何传输媒介）的物理接口细节（Telnet,FTP和e-mail等）
  • 网络层：处理分组在网络中的活动，例如分组选路（TCP和UDP）
  • 运输层：为两台主机上的应用程序提供端到端的通讯（IP,ICMP和IGMP）
  • 应用层：处理特定的应用程序细节（设备驱动程序及接口卡）

实例：运行FTP的两台主机

  • 大多数的网络应用程序都被设计成客户-服务器模式
  • 双方都有对应的一个或多个协议进行通讯
  • 应用程序通常是用户进程，而下三层一般在内核执行
  • 应用层关心应用程序的细节，下三层对应用程序一无所知，但它要处理所有的通信细节

通过路由器连接的两个网络

  • 端系统（end system）（两边的两台主机）
  • 中间系统（intermediate system）（中间的路由器）
  • 应用层和运输层使用端到端（end-to-end）协议
  • 网络层提供的是逐跳（hop-to-hop）协议
  • 网络ip提供的是一种不可靠的服务，它只是尽可能快的把分组从源结点送到目的结点，但不提供可靠的运输层
  • 互联网的目的之一就是在应用程序中隐藏所有的屋里细节

TCP/IP协议族中不同层次的协议

  • TCP使用不可靠的IP服务，并提供一种可靠的运输层服务
  • UDP为应用程序发送和接受数据报，和TCP不同，UDP是不可靠的。
  • IP是网络层上的主要协议，同时被TCP和UDP使用
  • ICMP是IP协议的附属协议
  • IGMP是Internet组管理协议。它用来把一个UDP数据报多播到多个主机
  • ARP（地址解析协议）和RARP（逆地址解析协议）是某些网络接口（如以太网和令牌环网）使用的特殊协议，用来转换IP层和网络接口层使用的地址。

互联网的地址

互联网上的每个接口必须有一个唯一的Internet地址（也称作IP地址）。IP地址长32bit。IP地址具有一定的结构，五类不同的互联网地址格式如图1-5所示。

说明：

  • 多接口主机具有多个IP地址，其中每个接口都对应一个IP地址。

  • 有三类IP地址：单播地址（目的端为单个主机）、广播地址（目的端为给定网络上的所有主机）以及多播地址（目的端为同一组内的所有主机）。

域名系统

在TCP/IP领域中，域名系统（DNS）是一个分布的数据库，由它来提供IP地址和主机名之间的映射信息。

封装

  • 以太网数据帧的物理特征是其长度必须在46~1500字节之间
  • 以太网的帧首部也有一个16bit的帧类型域（ip,arp,rarp）
  • IP在首部中存放一个长度为8bit的数值，称作协议域（icmp,igmp,tcp,udp,esp,gre）。1表示为ICMP协议，2表示为IGMP协议，6表示为TCP协议，17表示为UDP协议
  • TCP和UDP都用一个16bit的端口号来表示不同的应用程序（ftp,telnet,http）

分用

当目的主机收到一个以太网数据帧时，数据就开始从协议栈中由底向上升，同时去掉各层协议加上的报文首部。每层协议盒都要去检查报文首部中的协议标识，以确定接受数据的上层协议。这个过程称作分用。

客户-服务器模型

大部分网络应用程序在编写时都假设一端是客户，另一端是服务器，其目的是为了让服务器为客户提供一些特定的服务。服务分为两种类型：重复型和并发型。

重复型服务器

1）等待一个客户请求的到来。
2）处理客户请求。
3）发送响应给发送请求的客户。
4）返回1）步。

重复型服务器主要的问题发生在2）状态。在这个时候，它不能为其他客户机提供服务。

并发型服务器

1）等待一个客户请求的到来。
2）启动一个新的服务器来处理这个客户的请求。在这期间可能生成一个新的进程、任务或线程，并依赖底层操作系统的支持。这个步骤如何进行取决于操作系统。生成的新服务器对客户的全部请求进行处理。处理结束后，终止这个新服务器。

3）返回1）步。

并发服务器的优点在于它是利用生成其他服务器的方法来处理客户的请求。每个客户都有它自己对应的服务器。如果操作系统允许多任务，那么就可以同时为多个客户服务。

端口号

  • 服务器一般都是通过知名端口号来识别的（ftp 21,telnet 23）
  • 客户端端口号又称作临时端口号（即存在时间很短暂）
  • 大多数TCP/IP实现给临时端口分配1024~5000之间的端口号
  • 大于5000的端口号是为其他服务器预留的（Internet上并不常用的服务）

链路层

引言

从图1-4可以看出，在TCP/IP协议族中，链路层主要有三个目的：

  • 为IP模块发送和接收IP数据报；
  • 为ARP模块发送ARP请求和接收ARP应答。
  • 为RARP发送RARP请求和接收RARP应答。

TCP/IP支持多种不同的链路层协议，这取决于网络所使用的硬件，如以太网、令牌环网、FDDI（光纤分布式数据接口）及RS-232串行线路等。

以太网和IEEE 802封装

以太网

  • 以太网这个术语一般是指数字设备公司、英特尔公司和Xerox公司在1982年联合公布的一个标准
  • 它采用一种称作CSMA/CD的媒体接入方法。
  • 它的速率为10Mb/s，地址为48bit

IEEE 802封装

  • 802.3针对整个CSMA/CD网络
  • 802.4针对令牌总线网络
  • 802.5针对令牌环网络
  • 这三者的共同特性由802.2标准来定义，那就是802网络共有的逻辑链路控制（LLC）

封装格式

  • 两种帧格式都采用48bit(6字节)的目的地址和源地址
  • ARP和RARP协议对32bit的IP地址和48bit的硬件地址进行映射
  • 802定义的有效长度值与以太网的有效类型值无一相同，这样就可以对两种帧格式进行区分
  • 母的服务访问点（DSAP）和源服务访问点（SSAP）的值都设为0xaa。Ctr1字段的值设为3.随后的3个字节orgcode都置为0.再接下来的2个字节类型字段和以太网帧格式一样。
  • 802.3规定数据分布必须至少为38字节，而对于以太网，则要求最少要有46字节。为了保证这一点，必须在不足的空间插入填充（pad）字节。

SLIP：串行线路IP

SLIP的全称是Serial Line IP。它是一种在串行线路上对IP数据报进行封装的简单形式。SLIP适用于家庭中每台计算机几乎都有的RS-232串行端口和高速调制解调器接入Internet。下面的规则描述了SLIP协议定义的帧格式：

  • IP数据报以一个称作END（0xc0）的特殊字符结束。同时，为了防止数据报到来之前的线路噪声被当成数据报内容，大多数实现在数据报的开始处也传一个END字符。
  • 如果IP报文中某个字符为END，那么就要连续传输两个字节0xdb和0xdc来取代它。0xdb这个特殊字符被称作SLI的ESC字符。
  • 如果IP报文中某个字符为SLIP的ESC字符，那么就要连续传输两个字节0xdb和0xdd来取代它。

图2-2中的例子就是含有一个END字符和一个ESC字符的IP报文。

SLIP是一种简单的帧封装方法，值得一提的缺陷：

  • 每一端必须知道对方的IP地址。没有办法把本端的IP地址通知给另一端。
  • 数据帧中没有类型字段（类似于以太网中的类型字段）。如果一条串行线路用于SLIP，那么它不能同时使用其他协议。
  • SLIP没有在数据帧中加上检验和（类似于以太网中的CRC字段）。如果SLIP传输报文被线路噪声影响而发生错误，只能通过上层协议来发现。

尽管存在这些缺点，SLIP仍然是一种广泛使用的协议。

PPP：点对点协议

PPP点对点协议修改了SLIP协议中的所有缺陷。包括三个部分：

  • 在串行链路上封装IP数据报的方法。PPP既支持数据为8位和无奇偶检验的异步模式，还支持面向比特的同步链接。
  • 建立、配置及测试数据链路的链路控制协议（LCP：Link Control Protocol）。它允许通信双方进行协商，以确定不同的选项。
  • 针对不同网络层协议的网络控制协议（NCP：Network Control Protocol）体系。

图2-3是PPP数据帧的格式。

  • 每一帧都以标志字符0x7e开始和结束。紧接着是一个地址字节，值始终是0xff，然后是一个值为0x03的控制字节。
  • 协议字段，类似于以太网中类型字段的功能。当它的值为0x0021时，表示信息字段是一个 IP数据报；值为0xc021时，表示信息字段是链路控制数据；值为0x8021时，表示信息字段是网络控制数据。
  • CRC字段（或FCS，帧检验序列）是一个循环冗余检验码，以检测数据帧中的错误。
  • 标志字符0x7e出现在信息字段中时，PPP需要对它进行转义。

总的来说，PPP比SLIP具有下面这些优点：

  • PPP支持在单根串行线路上运行多种协议，不只是IP协议；
  • 每一帧都有循环冗余检验；
  • 通信双方可以进行IP地址的动态协商(使用IP网络控制协议)；
  • 与CSLIP类似，对TCP和IP报文首部进行压缩；
  • 链路控制协议可以对多个数据链路选项进行设置。

为这些优点付出的代价是在每一帧的首部增加3个字节，当建立链路时要发送几帧协商数据，以及更为复杂的实现。

环回接口

  • 传给换回地址（一般是127.0.0.1）任何数据均作为IP输入（都能ping通）
  • 传给广播地址或多播地址报复制一份传给环回接口，然后送给环回接口，然后送到以太网上。这是因为广播传送和多播传送的定义包含主机本身
  • 任何传给该主机IP地址的数据均送到环回接口

MTU和路径MTU

  • 以太网和802.3对数据帧的长度都有一个限制，其最大值分别是1500和1492字节。链路层的这个特征称作MTU，最大传输单元
  • 如果IP层有一个数据报要传，而且数据的长度比链路层的MTU还大，那么IP层就需要进行分片（fragmentation）,把数据报分成若干片，这样每一片都小于MTU
  • 点到点的链路层（如SLIP和PPP）和MTU并非指的是网络媒体的物理特性。相反，它是一个逻辑限制，母的是为交互使用提供足够快的响应时间
  • 两台通信主机路径中的最小MTU。它被称作路径MTU
  • 路径MTU在两个方向上不一定是一致的
  • MTU是计算出方向的

串行线路吞吐量计算

如果线路速率是9600b/s，而一个字节有8bit，加上一个起始比特和一个停止比特，那么线路的速率就是960B/s（字节/秒）。以这个速率传输一个1024字节的分组需要1066ms。如果用SLIP链接运行一个交互式应用程序，同时还运行另一个应用程序如FTP发送或接收1024字节的数据，那么一般来说就必须等待一半的时间（533ms）才能把交互式应用程序的分组数据发送出去。

对于交互应用来说，等待533ms是不能接受的。研究表明，交互响应时间超过100~200ms就被认为是不好的，这是发送一份交互报文出去后，直到接收到响应信息（通常是出现一个回显字符）为止的往返时间。

注意：我们对平均等待时间的计算（传输最大数据帧所需时间的一半）只适用于SLIP链路（或PPP链路）在交互通信和大块数据传输这两种情况下。

IP：网际协议

IP介绍

  • IP是TCP/IP协议族中最为核心的协议。所有的TCP、UDP、ICMP及IGMP数据都以IP数据报格式传输
  • IP提供不可靠、无连接的数据报传送服务
  • 不可靠（unreliable）的意思是它不能保证IP数据报能成功到达目的地。IP仅提供最好的传输服务。如果发生某种错误时，如某个路由器暂时用完了缓冲区，IP有一个简单的错误处理算法：丢弃该数据报，然后发送ICMP消息报给信源端。任何要求的可靠性必须由上层来提供（如TCP）
  • 无连接（connectionless）这个术语的意思是IP并不维护任何关于后续数据报的状态信息。每个数据报的处理是互相独立的。IP数据报可以不按发送顺序接收。如果一信源向相同的信宿发送两个连续的数据报（先是A，然后是B），每个数据报都是独立地进行路由选择，课时选择不同的路线，因此B可能在A到达之前先到达。

IP首部

  • 4个字节的32bit值以下面的次序传输：首先是0~7bit，其次8~15bit，然后16~23bit，最后是24、·31bit。这种传输次序称作big endian字节序。由于TVP|IP首部中所有的二进制整数在网络中传输时都要求以这种次序，因此它又称作网络字节序
  • 目前的协议版本号是4，因此IP有时也称作IPv4
  • 首部长度指的是首部占32bit字的数目，包括任何选项。由于它是一个4bit字段，因此首部最长为60个字节
  • 服务类型（TOS）字段包括一个3bit的优先权子字段（现在已被忽略），4bit的TOS字段和1bit未用位但必须置0
  • 服务类型（TOS）字段包括一个3 bit的优先权子字段（现在已被忽略），4 bit的TOS子字段和1 bit未用位，但必须置0。4 bit的TOS分别代表：最小时延、最大吞吐量、最高可靠性和最小费用。 4 bit中只能置其中1 bit。如果所有4 bit均为0，那么就意味着是一般服务。图3-2列出了对不同应用建议的TOS值。

注意：现在大多数的TCP/IP实现都不支持TOS特性。

  • 总长度字段是指整个IP数据报的长度，以字节为单位。由于该字段长16比特，所以IP数据报最长可达65535字节。
    注意：尽管可以传送一个长达65535字节的IP数据报，但是大多数的链路层都会对它进行分片。而且，主机也要求不能接收超过576字节的数据报。
  • 标识字段唯一地标识主机发送的每一份数据报。通常每发送一份报文它的值就会加1。
  • TTL生存时间字段设置了数据报可以经过的最多路由器数。它指定了数据报的生存时间。 TTL的初始值由源主机设置（通常为32或64），一旦经过一个处理它的路由器，它的值就减去1。当该字段的值为0时，数据报就被丢弃，并发送ICMP报文通知源主机。
  • 协议字段，它可以识别是哪个协议向IP传送数据。
  • 首部检验和字段是根据IP首部计算的检验和码。
  • 如果结果不是全1（即检验和错误），那么IP就丢弃收到的数据报。但是不生成差错报文，由上层去发现丢失的数据报并进行重传
  • 由于路由器经常只修改TTL字段（减1），因为当路由器转发一份报文时可以增加它的检验和，而不需要对IP整个首部进行重新计算
  • 任选项，是数据报中的一个可变长的可选信息。这些选项很少被使用，并非所有的主机和路由器都支持这些选项。

IP路由选择

路由表中的包含信息

  • 目的IP地址。
    它既可以是一个完整的主机地址，也可以是一个网络地址，由该表目中的标志字段来指定。主机地址有一个非0的主机号，以指定某一特定的主机，而网络地址中的主机号为0，以指定网络中的所有主机（如以太网，令牌环网）。
  • 下一跳路由器的IP地址，或者有直接连接的网络IP地址。
    下一跳路由器是指一个在直接相连网络上的路由器，通过它可以转发数据报。下一跳路由器不是最终的目的，但是它可以把传送给它的数据报转发到最终目的。
  • 标志。
    其中一个标志指明目的IP地址是网络地址还是主机地址，另一个标志指明下一跳路由器是否为真正的下一跳路由器，还是一个直接相连的接口。
  • 为数据报的传输指定一个网络接口。

路由选择完成的功能

IP路由选择是逐跳地进行的。IP并不知道到达任何目的的完整路径（当然，除了那些与主机直接相连的目的）。所有的IP路由选择只为数据报传输提供下一跳路由器的IP地址。它假定下一跳路由器比发送数据报的主机更接近目的，而且下一跳路由器与该主机是直接相连的。

  • 搜索路由表，寻找能与目的IP地址完全匹配的表目（网络号和主机号都要匹配）。如果找到，则把报文发送给该表目指定的下一站路由器或直接连接的网络接口（取决于标志字段的值）。
  • 搜索路由表，寻找能与目的网络号相匹配的表目。如果找到，则把报文发送给该表目指定的下一站路由器或直接连接的网络接口。
  • 搜索路由表，寻找标为“默认”的表目。如果找到，则把报文发送给该表目指定的下一站路由器

实例

对于这个例子需要指出一些关键点：

  • 该例子中所有主机和路由器都使用了默认路由。事实上，大多数主机和一些路由器可以用默认路由来处理任何目的，除非它在本地局域网上
  • 数据报中的目的IP地址始终不发生任何变化。所有的路由选择决策都是基于这个目的IP地址
  • 每个链路层可能具有不同数据帧首部，而且链路层的目的地址（如果有的话）始终指的是下一站的链路层地址。在例子中，两个以太网封装了含有下一站以太网地址的链路层首部，但是SLIP链路没有这样做。以太网地址一般通过ARP获得。

子网掩码

任何主机在引导时进行的部分配置是指定主机IP地址。除了此以外，还需要知道有多少比特用于子网号和多少比特用于主机号。这是在引导过程中通过子网掩码来确定的。子网掩码是一个32 bit的值，其中值为1的比特留给网络号和子网号，为0的比特留给主机号。

例如：一个B类地址的两种不同的子网掩码格式。

第一个例子，子网号和主机号都是8 bit。第二个例子，子网号是10 bit，主机号是6 bit。

特殊情况的IP地址

  • 0表示所有的比特位全为0；-1表示所有的比特位全为1；netid、subnetid和hostid分别表示不为全0或全1的对应字段。子网号栏为空表示该地址没有进行子网划分
  • 表的头两项是特殊的源地址，中间是特殊的环回地址，最后四项是广播地址
  • 表中的头两项，网络号为0，如主机使用BOOTP协议确定本机IP地址时只能作为初始化过程中的源地址出现

ARP：地址解析协议

ARP介绍

  • 当一台主机把以太网数据帧发送到位于同一局域网上的另一台主机时，是根据48bit的以太网地址来确定目的接口的。设备驱动程序从不检查IP数据报中的目的IP地址
  • 地址解析为这两种不同的地址形式提供映射：32bit的IP地址和数据链路层使用的任何类型的地址（FR环境）
  • ARP为IP地址到对应的硬件地址之间提供动态映射。我们之所以用动态这个词是因为这个过程是自动完成的，一般应用程序用户或系统管理员不必关心
  • RARP是被那些没有磁盘驱动器的系统使用（一般是无盘工作站或X终端），它需要系统管理员进行手工设置

一个例子

当敲入以下命令时：ftp bsdi（主机名），会发生下列步骤：

  • 应用程序FTP客户端调用函数gethostbyname把主机名（bsdi）转换成32 bit的IP地址。这个转换过程或者使用DNS，或者在较小网络中使用一个静态的主机文件（/etc/hosts）。
  • FTP客户端请求TCP用得到的IP地址建立连接。
  • TCP发送一个连接请求分段到远端的主机，即用上述IP地址发送一份IP数据报。
  • 如果目的主机在本地网络上（如以太网、令牌环网或点对点链接的另一端），那么IP数据报可以直接送到目的主机上。如果目的主机在一个远程网络上，就通过IP选路函数来确定位于本地网络上的下一站路由器地址，并让它转发IP数据报。
  • 假定是一个以太网，那么发送端主机必须把32 bit的IP地址变换成48 bit的以太网地址。从逻辑Internet地址到对应的物理硬件地址需要进行翻译，这是ARP的功能。
  • ARP发送一份称作ARP请求的以太网数据帧给以太网上的每个主机，这个过程称作广播。ARP请求数据帧中包含目的主机的IP地址（主机名为bsdi），意思是“如果你是这个IP地址的拥有者，请回答你的硬件地址。”
  • 目的主机的ARP层收到这份广播报文后，识别出这是发送端在寻问它的IP地址，于是发送一个ARP应答。这个ARP应答包含IP地址及对应的硬件地址。
  • 收到ARP应答后，使ARP进行请求-应答交换的IP数据报现在就可以传送了。
  • 发送IP数据报到目的主机。

说明：

  • 在ARP背后有一个基本概念，就是网络接口有一个硬件地址（一个48 bit的值，标识不同的以太网或令牌环网络接口）。
  • 在硬件层次上进行的数据帧交换必须有正确的接口地址。但是，TCP/IP有自己的地址：32 bit的IP地址。知道主机的IP地址并不能让内核发送一帧数据给主机。内核（如以太网驱动程序）必须知道目的端的硬件地址才能发送数据。
  • ARP的功能是在32 bit的IP地址和采用不同网络技术的硬件地址之间提供动态映射。
  • 点对点链路不使用ARP。当设置这些链路时（一般在引导过程进行），必须告知内核链路每一端的IP地址。像以太网地址这样的硬件地址并不涉及。

ARP背后的一个基本概念

  • 在ARP背后有一个概念，那就是网络接口有一个硬件地址（一个48bit的值，标识不同的以太网或令牌环网络接口）。在硬件层次上进行的数据帧交换必须有正确的接口地址。但是，TCP|IP有自己的地址：32bit的IP地址。知道主机的IP地址并不能让内核发送一帧数据给主机。内核必须知道目的端的硬件地址才能发送数据。ARP的功能是在32bit的IP地址和采用不同网络技术的硬件地址之间提供动态映射
  • 点对点链路不好使用ARP。当设置这些链路时（一般在引导过程进行），必须告知内核链路每一端IP的地址。像以太网地址这样的硬件地址并不涉及

ARP高速缓存

  • ARP高效运行的关键是由于每个主机上都有一个ARP高速缓存。这个高速缓存存放了最近Intern et地址到硬件地址之间的映射记录。高速缓存中每一项的生存时间一般为20分钟，起始时间从被创建时开始算起。
  • 可用arp命令来检查ARP高速缓存。-a的意思是显示高速缓存中所有的内容。
  • 48 bit的以太网地址用6个十六进制的数来表示，中间以冒号隔开。

PC

1
2
arp -a	查看缓存
arp -d  清除缓存

路由器

1
2
show arp	查看缓存
clear arp	清除缓存

ARP的分组格式

在以太网上解析IP地址时，ARP请求和应答分组的格式如图4-3所示（ARP可以用于其他类型的网络，可以解析IP地址以外的地址。紧跟着帧类型字段的前四个字段指定了最后四个字段的类型和长度）

ARP包字段分析

  • 前两个字段是以太网的源地址和目的地址。目的地址为全1的地址是广播地址。电缆上的所有以太网接口都要接收广播的数据帧。
  • 以太网帧类型表示后面数据的类型。对于ARP请求或应答来说，该字段的值为0x0806。
  • 硬件类型字段表示硬件地址的类型。它的值为1即表示以太网地址。
  • 协议类型字段表示要映射的协议地址类型。它的值为0x0800即表示IP地址。
  • 硬件地址长度和协议地址长度分别指出硬件地址和协议地址的长度，以字节为单位。对于以太网上IP地址的ARP请求或应答来说，它们的值分别为6和4。
  • 操作字段指出四种操作类型，它们是ARP请求（值为1）、ARP应答（值为2）、RARP请求（值为 3）和RARP应答（值为4）。

ARP代理

ARP代理通俗地说，就是由中间设备代替其他主机响应arp请求。下图展现了ARP代理工作的主要过程：
Proxy ARP应该使用主机没有配置默认网关或没有任何路由策略的网络上

ARP代理工作的过程说明

  • 192.168.0.16/16主机向外发送目的主机为192.168.1.3/24的ARP请求报文；
  • 网关收到0.16的ARP请求报文，由于网关开启了ARP代理的功能，因此网关代替1.3向0.16发送ARP响应数据报；
  • 网关向1.0/24网段发送1.3的ARP请求报文；
  • 1.3收到后，发送ARP响应报文。

ARP代理带来的问题

在开启ARP代理功能之后，很可能会导致地址冲突等类似故障的产生，如在下图的网络环境下，将会产生一系列的不稳定的故障现象产生。

正因为如此，我们在实际工作的环境中对于ARP代理功能的应用需要慎重一些，尽量避免针对整个网段使用ARP代理功能，最好只针对需要使用ARP代理功能来实现某些特殊功能需求的少数IP开启。

ARP代理在实际工作中的应用

AnyIP

AnyIP是指机器随便使用什么IP地址或网关信息，只要接入网络中都可以实现访问的需求。这个技术被广泛的应用在soho级网关产品中，特别是在宾馆、会议室、广场等公共场所，为网络使用者提供了很大的便利。
其工作原理就是利用了ARP代理的功能，在收到非本地IP地址的ARP请求报文时，对其进行ARP响应。这样，那些收到ARP响应的主机就会将相关的数据包发送至网关设备接口处，再由网关设备转发出去，从而实现了上网的功能。

网关地址映射

在很多网关设备上，都支持将内网的服务器映射为公网地址对外提供服务，以达到隐藏内部网络的目的，这种地址映射也是利用ARP代理技术来实现的，我们来简单看一下下图所示的地址映射的工作过程：

在这个过程中，当来自互联网的数据访问产生了对映射外网地址202.102.X.2的ARP请求报文，正常情况下，因为这个地址的真实主机并不存在，发送端是不会收到来自202.102.X.2的ARP响应报文的。但是，由于网关上启用了针对202.102.X.2的ARP代理功能，网关会替代202.102.X.2发送ARP响应报文。从而实现了地址映射访问的需求。

免费ARP

它是指主机发送ARP查找自己的IP地址。通常，它发生在系统引导期间进行接口配置的时候。免费ARP有两个作用：

  • 一个主机可以通过它来确定另一个主机是否设置了相同的IP地址。主机bsdi并不希望对此请求有一个回答。但是，如果收到一个回答，那么就会在终端日志上产生一个错误信息“以太网：a:b:c:d:e:f发送来重复的IP地址”。这样就可以警告系统管理员，某个系统有不正确的设置。
  • 如果发送免费ARP的主机正好改变了硬件地址（很可能是主机关机了，并换了一块接口卡，然后重新启动），那么这个分组就可以使其他主机高速缓存中旧的硬件地址进行相应的更新。一个比较著名的ARP协议事实是，如果主机收到某个IP地址ARP请求，而且它已经在接收者的高速缓存中，那么就要用ARP请求中的发送端硬件地址（如以太网地址）对高速缓存中相应的内容进行更新。主机接收到任何ARP请求都要完成这个操作（ARP请求是在网上广播的，因此每次发送ARP请求时网络上的所有主机都要这样做）
  • 通过发送含有备份硬件地址和故障服务器的IP地址的免费ARP请求，使得备份文件服务器可以顺利地接替故障服务器进行工作。这使得所有目的地为故障服务器的报文都被送到备份服务器那里，客户程序不用关心原来的服务器是否出了故障

RARP：逆地址解析协议

引言

具有本地磁盘的系统引导时，一般是从磁盘上的配置文件中读取IP地址。但是无盘机，如X终端或无盘工作站，则需要采用其他方法来获得IP地址。
网络上的每个系统都具有唯一的硬件地址，它是由网络接口生产厂家配置的。无盘系统的RARP实现过程是从接口卡上读取唯一的硬件地址，然后发送一份RARP请求（一帧在网络上广播的数据），请求某个主机响应该无盘系统的IP地址（在RARP应答中）。

RARP的分组格式

RARP分组的格式与ARP分组基本一致。它们之间主要的差别是RARP请求或应答的帧类型代码为0x8035，且RARP请求的操作代码为3，应答操作代码为4。

注意：RARP请求以广播方式传送，应答一般是单播(unicast)传送的。

RARP服务器的设计

RARP在概念上很简单，但是一个RARP服务器的设计与系统相关而且比较复杂。相反，提供一个ARP服务器很简单，通常是TCP/IP在内核中实现的一部分。由于内核知道IP地址和硬件地址，因此当它收到一个询问IP地址的ARP请求时，只需用相应的硬件地址来提供应答就可以了。

作为用户进程的RARP服务器

RARP服务器的复杂性在于：

  • 服务器一般要为多个主机（网络上所有的无盘系统）提供硬件地址到IP地址的映射，该映射包含在一个磁盘文件中。由于内核一般不读取和分析磁盘文件，因此RARP服务器的功能就由用户进程来提供，而不是作为内核的TCP/IP实现的一部分。
  • RARP请求是作为一个特殊类型的以太网数据帧来传送的（帧类型字段值为0x8035），说明RARP服务器必须能够发送和接收这种类型的以太网数据帧。

每个网络有多个RARP服务器

RARP服务器实现的一个复杂因素是RARP请求是在硬件层上进行广播的，这意味着它们不经过路由器进行转发。为了让无盘系统在RARP服务器关机的状态下也能引导，通常在一个网络上（例如一根电缆）要提供多个RARP服务器。
当服务器的数目增加时（以提供冗余备份），网络流量也随之增加，因为每个服务器对每个RARP请求都要发送RARP应答。发送RARP请求的无盘系统一般采用最先收到的RARP应答。（对于ARP，只有一台主机发送ARP应答）。每个RARP服务器同时应答，这样会增加以太网发生冲突的概率。

ICMP：Internet控制报文协议

ICMP介绍


  • ICMP经常被认为是IP层的一个组成部分。它传递差错报文以及其他需要注意的信息。ICMP报文通常被IP层或更高层协议（TCO或UDP）使用。一些ICMP报文把差错报文返回给用户进程
  • ICMP报文是在IP数据内部被传输的
  • ICMP报文的格式如图6-2所示。所有报文的前4个字节都是一样的，但是剩下的其他字节则互不相同
  • 类型字段可以有15个不同的值，以描述特定类型的ICMP报文。某些ICMP报文还使用代码字段的值来进一步描述不同的条件
  • 检验和字段覆盖整个ICMP报文。使用的算法与IP首部检验和算法相同。ICMP的检验和是必须的

ICMP报文的类型

  • 不同类型由报文中的类型字段和代码字段来共同决定。
  • ICMP是一份查询报文还是一份差错报文。
  • 因为对ICMP差错报文有时需要作特殊处理，因此需要对它们进行区分。例如，在对ICMP差错报文进行响应时，永远不会生成另一份ICMP差错报文（如果没有这个限制规则，可能会遇到一个差错产生另一个差错的情况，而差错再产生差错，这样会无休止地循环下去）。
  • 当发送一份ICMP差错报文时，报文始终包含IP的首部和产生ICMP差错报文的IP数据报的前8个字节。这样，接收ICMP差错报文的模块就会把它与某个特定的协议（根据IP数据报首部中的协议字段来判断）和用户进程（根据包含在IP数据报前8个字节中的TCP或UDP报文首部中的TCP或UDP端口号来判断）联系起来。

下面各种情况都不会导致产生ICMP差错报文

  • ICMP差错报文（ICMP查询报文可能会产生ICMP差错报文）。
  • 目的地址是广播地址或多播地址的IP数据报。
  • 作为链路层广播的数据报。
  • 不是IP分片的第一片。
  • 源地址不是单个主机的数据报。即源地址不能为零地址、环回地址、广播地址或多播地址。

这些规则是为了防止过去允许ICMP差错报文对广播分组响应所带来的广播风暴。

ICMP地址掩码请求与应答

ICMP地址掩码请求用于无盘系统在引导过程中获取自己的子网掩码。系统广播它的ICMP请求报文，报文格式如图6-4所示：

说明：

  • 标识符和序列号字段由发送端任意选择设定，这些值在应答中将被返回。这样，发送端就可以把应答与请求进行匹配。
  • 广播的定义是指局域网上的所有主机，因此它必须包括发送主机在内。当以太网驱动程序识别出目的地址是广播地址后，它就把分组送到网络上，同时传一份拷贝到环回接口。
  • 通常，应答地址必须是单播地址，除非请求端的源IP地址是0.0.0.0。

ICMP时间戳请求与应答

ICMP时间戳请求允许系统向另一个系统查询当前的时间。返回的建议值是自午夜开始计算的毫秒数，协调的统一时间(Coordinated Universal Time, UTC)。

说明：

  • 这种报文的好处是：提供了毫秒级的分辨率，而利用其他方法从别的主机获取的时间（如某些Unix系统提供的rdate命令）只能提供秒级的分辨率。
  • 缺陷是：返回的时间是从午夜开始计算的，因此调用者必须通过其他方法获知当时的日期。

ICMP时间戳请求和应答报文格式如图6-6所示：

请求端填写发起时间戳，然后发送报文。应答系统收到请求报文时填写接收时间戳，在发送应答时填写发送时间戳。

ICMP端口不可达差错

端口不可达报文是一种ICMP差错报文，它是ICMP目的不可到达报文中的一种。ICMP不可达报文的一般格式如图6-10所示。

说明：

  • ICMP的一个规则是：ICMP差错报文必须包括生成该差错报文的数据报IP首部（包含任何选项），还必须至少包括跟在该IP首部后面的前8个字节。
  • 导致差错的数据报中的IP首部要被送回的原因是因为IP首部中包含了协议字段，使得ICMP可以知道如何解释后面的8个字节。TCP和UDP首部的前8个字节包括源端口和目的端口。

ICMP覆盖的范围很广，从致命差错到信息差错，即使在一个给定的系统实现中，对每个ICMP报文的处理都是不相同的。

ICMP报文的4.4BSD处理

由于ICMP覆盖的范围很广，从致命差错到信息差错，因此即使在一个给定的系统实现中，对每个ICMP报文的处理都是不相同的。

  • 如果最后一列标明是“内核”，那么ICMP就由内核来处理
  • 如果最后一列指明是“用户进程”，那么报文就被传送到所有在内核中登记用户进程，以读取收到的ICMP报文
  • 如果不存在任何这样的用户进程，那么报文就悄悄地被丢弃（这些用户进程还会收到所有其它类型的ICMP报文的拷贝，虽然它们应该由内核来处理，当然用户进程只有在内核处理以后才能收到这些报文）。有一些报文完全被忽略
  • 如果最后一列标明的是引号内的一串字符，那么它就是对应的Unix差错。

Ping程序

Ping介绍

  • “ping”这个名字源于声纳定位操作。Ping程序由Mike Muuss编写，目的是为了测试另一台主机是否可达。该程序发送一份ICMP回显请求报文给主机，并等待返回ICMP回显应答
  • 可以用Ping程序来确定问题出在哪里。Ping程序还能测出到这台主机的往返时间，以表明该主机离我们有多远
  • 一台主机的可达性可能不只取决于IP层是否可达，还取决于使用何种协议以及端口号。Ping程序的运行结果可能显示某台主机不可达，但我们可以用Telnet远程登录到该台主机是25号端口

Ping程序

  • 称发送回显请求的ping程序为客户，而称被ping的主机为服务器。大多数的TCP|IP实现都在内核中直接支持Ping服务器–这种服务器不是一个用户进程
  • 对于其他类型的ICMP查询报文，服务器应该响应标识符和序列号字段。另外，客户发送的选项数据必须回显，假设客户对这些信息都会感兴趣
  • Unix系统在实现ping程序时是把ICMP报文中的标识符字段置成发送进程的ID号。这样即使在同一台主机上同时运行了多个ping程序实例，ping程序也可以识别出返回的信息
  • 在windows下，不管开多个窗口ping的identifier都是相同的，而且每增加一个出去的ping包序列号增加256

IP记录路由选项

  • 大多数不同版本的ping程序都提供-R选项，以提供记录路由的功能。它使得[ing程序在发送出来的IP数据报中设置IPRR选项（该IP数据报包含ICMP回显请求报文）。这样，每个处理该数据报的路由器都把它的IP地址放入选项字段中。当数据报到达目的端时，IP地址清单应该赋值到ICMP回显应答中，这样返回途中所经过的路由器地址也被加入清单中。当Ping程序收到回显应答时，它就打印出这份IP地址清单
  • 源端主机生成RR选项，中间路由器对RR选项的处理，以及把ICMP回显请求中的RR清单复制到ICMP回显应答中，所有这些都是选项功能。幸运的是，现在的大多数系统都支持这些选项功能，只能有一些系统不把ICMP请求的IP清单赋值到ICMP应答中。
  • 但是，最大的问题是IP首部中只有有限的空间来存放IP地址。IP首部中的首部长度字段只有4bit，因此整个IP首部最长只能包括15个32bit长的字（即60个字节）。由于IP首部固定长度为20字节，RRR选项用去3个字节，这样只剩下37个字节（60-20-3）来存放IP地址清单，也就是说只能存放9个IP地址

IP时间戳选项

  • 时间戳选项的代码为0x44。其他两个字段len和ptr与记录路由选项相同：选项的总长度（一般为36或40）和指向下一个可用时间的指针（5，9，13等）
  • 接下来的两个字段是4bit的值：OF表示溢出字段，FL表示标志字段。时间戳选项的操作
  • 时间戳的取值一般为自UTC午夜开始计的毫秒数，与ICMP时间戳请求和应答相类似。如果路由器不使用这种格式，它就可以插入任何它使用的时间表示格式，但是必须打开时间戳中的高位以表明为非标准值
  • 与我们遇到的记录路由选项所受到的限制相比，时间戳选项遇到情况要更坏一些。如果我们要同时记录IP地址和时间戳（标志位为1），那么就可以同时存入其中的四对值。只记录时间戳是没有用处的，因为没有标明时间戳与路由器之间的对应关系

Traceroute程序

  • 由Van Jacobson编写的Traceroute程序是一个能更深入探索TCP|IP协议的方便可用的工具
  • Traceroute程序可以让我们看到IP数据报从一台主机传到另一台主机所经过的路由
  • Traceroute程序还可以让我们使用IP源路由选项

Traceroute和IP路径记录选项的比较

我们描述了IP记录路由选项（RR）。为什么不使用这个选项而另外开发一个新的应用程序？有三个方面的原因。

  • 首先，原先并不是所有的路由器都支持记录路由选项，因此该选项在某些路径上不能使用（Traceroute程序不需要中间路由器具备任何特殊的或可选的功能）
  • 其次，记录路由一般是单向的选项。发送端设置了该选项，那么接收端不得不从收到的IP首部中提取所有的信息，然后全部返回给发送端.大多数Ping服务器的实现（内核中的ICMP回显应答功能）把接收到的RR清单返回，但是这样使得记录下来的IP地址翻了一番（一来一回）。
  • 最后一个原因也是最主要的原因是，IP首部中留给选项的空间有限，不能存放当前大多数的路径

Traceroute程序的操作

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

IP源选路选项

源站选项（source routing）的思想是由发送者指定路由，它可以采用以下两种形式：

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

IP源站选路的操作机制

源站路由选项的实际称呼为“源站及记录路由”（对于宽松的源站选路和严格的源路选路，分别用LSRR和SSRR表示），这是因为在数据报沿路由发送过程中，对IP地址清单进行了更新。下面是其运行过程：

  • 发送主机从应用程序接收源站路由清单，将第1个表项去掉（它是数据报的最终目的地址），将剩余的项移到1个项中，并将原来的目的地址作为清单的最后一项。指针仍然指向清单的第1项（即，指针的值为4）
  • 每个处理数据报的路由器检查其是否为数据报的最终地址。如果不是，则正常转发数据报（在这种情况下，必须指明宽松源站选路，否则就不能接收到该数据报）
  • 如果该路由器是最终目的，且指针不大于路径的长度，那么（1）由ptr所指定的清单中的下一个地址就是数据报的最终目的地址；（2）由外接口响应的IP地址取代刚才使用的源地址；（4）指针加4
  • Host Requirements RFC指明，TCP客户必须能指明源站选路，同时，TCP服务器必须能够接收源站选路，并且对于该TCP连接的所有报文段都能采用反向路由。如果TCP服务器下面接收到一个不同的源站选路，那么新的源路路由将取代旧的源路路由

IP选路

  • 选路是IP最重要的功能之一
  • 路由守护程序（daemon），通常这是一个用户进程
  • 在Unix系统中，大多数普通的守护程序都是路由程序和网关程序
  • 路由表经常被IP访问，但是它被路由守护程序更新的频度却要低得多
  • 当接收到ICMP重定向报文时，路由表也要被更新

  • 用netstat命令来显示路由表

选路的原理

IP搜索路由表的几个步骤：

  • 搜索匹配的主机地址
  • 搜索匹配的网络地址
  • 搜索默认表项（默认表项一般在路由表中被指定为一个网络表项，其网络号为0）
  • CISCO的选路策略（1.明细策略路由 2.明细路由 3.策略默认路由 4.默认路由）
  • IP执行选路机制，而路由守护程序则一般提供选路策略

初始化路由表

  • 每当初始化一个接口时（通常是用ifconfig命令设置接口地址），就为接口自动创建一个直接路由。对于点对点链路和环回接口来说，路由是到达主机（例如，设置H标志）。对于广播接口来说，如以太网，路由是到达网络
  • 到达主机或网络的路由如果不是直接相连的，那么就必须加入路由表
1
2
3
route add default sun 1
route add slip bsdi 1
route add 1.1.1.0 mask 255.255.255.0 1.1.1.1
  • 第三个参数（defalut和slip）代表目的端，第四个参数代表网关（路由器），最后一个参数代表路由的度量（metric）.route命令在度量值大于0时要为该路由设置G标志，否则，当耗费值为0时就不设置G标志

转发或不转发

  • 一般都假定主机不转发IP数据报，除非对它们进行特殊配置而作为路由器使用
  • 大多数伯克利派出来的系统都有一个内核变量ipforwarding
  • SumOS 4.1.x允许该变量可以有三个不同的值：-1表示始终不转发并且始终不改变它的值；0表示默认条件下不转发，但是当打开两个或更多个接口时就把值设为1；1表示始终转发。Solaris 2.x把这个值改为0（始终不转发）’1（始终转发）和2（在打开两个或更多个接口是才转发）
  • 较早版本的4.2BSD主机在默认条件下可以转发数据报，这给没有进行正确配置的系统带来了许多问题。这就是内核选项为什么要设成默认的“始终不转发”的原因，除非系统管理员进行特殊设置

ICMP重定向差错

  • 我们假定主机发送一份IP数据报给R1.这种选路决策经常发生，因为R1是该主机的默认路由
  • R1收到数据报并检查它的路由表，发现R2是发送数据报的下一站。当它把数据报发送给R2时，R1检测到它正在发送的接口与数据报达到接口是相同的（即主机和两个路由器所在的LAN）。这样就给路由器发送重定向报文给原始发送端提供了线索
  • R1发送一份ICMP重定向报文给主机，告诉它以后把数据报发送给R2而不是R1

UDP：用户数据报协议

UDP介绍

  • UDP是一个简单的面向数据报的运输层协议：进程的每个输出操作都正好产生一个UDP数据报，并组装成一份待发送的IP数据包
  • 这与面向流字符的协议不同，如TCP，应用程序产生的全体数据与真正发送的单个IP数据报可能没什么联系
  • UDP不提供可靠性：它把应用程序传给IP层的数据发送出去，但是并不保证它们能到达目的地
  • 应用程序必须关心IP数据报的长度。如果它超过网络的MTU，那么就要对IP数据报进行分片

UDP三大典型运用

查询类：DNS

  • 没有TCP三次握手包过程，快
  • 多个DNS同时查询

数据传输：TFTP

  • 停止等待协议，慢（需运用层确定数据）
  • 适合无盘工作站

语言视频流

  • 支持广播和组播
  • 支持丢包，保障效率

UDP首部

  • 端口号表示发送进程和接收进程
  • TCP端口号与UDP端口号是相互独立的。（rsh和syslog=514）
  • 尽管相互独立，如果TCP和UDP同时提供某种知名服务，两个协议通常选择相同的端口号。这纯粹是为了使用方便，而不是协议本事的要求（dns）
  • UDP长度字段指的是UDP首部和UDP数据的字节长度。该字段的最小值为8字节

UDP检验和

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

tcpdump输出

  • 三个系统有两个打开了UDP检验和选项
  • 送出的数据报与收到的数据报具有相同的检验和值（第3和第4行，第5和第6行）。从图11-3可以看出，两个IP地址进行了交换，正如两个端口号一样。伪首部和UDP首部中的其他字段都是相同的，就想数据回显一样。这再次表明UDP检验和（事实上，TCP|IP协议簇中所有的检验和）是简单的16bit和。它们检测不出交换两个16bit的差错

一个简单的例子

  • 在发送第一份数据报之前，发送端和接收端之间没有任何通信
  • 当收到数据时，接收端没有任何确认。在这个例子中，发送端并不知道零一端是否已经收到这些数据报
  • 每次运行程序时，源端的UDP端口号都发生变化。第一次是1108，然后是1110.客户程序使用ephemeral端口号一般在1024~5000之间

IP分片

  • IP把MTU与数据报长度进行比较
  • 如果需要则进行分片。分片可以发生在原始发送端主机上，也可以发送在中间路由器上。
  • 把一份IP数据报分片以后，只有到达目的地才进行重新组装（FR fragment）
  • 重新组装由目的端的IP层来完成，其目的是使分片和重新组装过程对运输层（TCP和UDP）是透明的
  • 已经分片过的数据报有可能会再次进行分片（可能不止一次）
  • 当IP数据报被分片后，每一片都成为一个分组，具有自己的IP首部中有足够的信息让接收端能正确组装这些数据报片
  • 尽管IP分片过程看起来是透明的，但有一点让人不想使用它：即使只丢失一片数据也要重传整个数据报
  • IP层本身没有超时重传的机制–由更高层来负责超时和重传（TCP有超市和重传机制，但UDP没有。一些UDP应用程序本身也执行超时和重传）。当来自TCP报文段的某一片丢失后，TCP在超时后会重发整个TCP报文段，该报文段对应于一份IP数据报。没有办法只能重传数据报中的一个数据报片
  • 如果对数据报分片的是中间路由器，而不是启事端系统，那么起始端系统就无法知道数据报是如何被分片的。就这个原因，要经常避免分片

IP分片：注意事项

  • 在分片时，除最后一片外，其他每一片中的数据部分（除IP首部外的其余部分）必须是8字节的整数倍
  • IP首部被复制到各个片中。但是，端口号在UDP首部，只能在第一片中被发现
  • 需要解释几个术语：IP数据报是指IP层端到端的传输单元（在分片之前和重新组装之后），分组是指在IP层和链路层之间的数据单元，一个分组可以是一个完整的IP数据报，也可以是IP数据报的一个分片

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

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

  • 在点到点的链路中，不要求两个方向的MTU为相同值
  • 在主机sun上运行tcpdump，观察SLIP链路，看什么时候发生分片。开始没有观察到分片，一切都很正常知道ping分组的数据长度从500增加到600字节。可以看到接收到的回显请求（仍然没有分片），但不见回显应答
  • Ping的时候DF置位（echo设置DF位，echo-reply也会设置DF位）

用Traceroute确定路径MTU

  • MTU值的个数是有限的，因此在我们的程序中有些由近似值构成的表，取下一个最小的MTU值来发送
  • 上面的测试中间设备不回送吓一跳的MTU，下面的测试回送了下一跳的MTU

采用UDP的路径MTU发现

  • Solaris发送650字节的udp包，并且DF被置位
  • 被bsdi丢弃，但是不回送MTU值
  • Solaris自以为是的对数据包进行分片（552 106两个片）


  • Solaris自以为是的对数据报进行分片（552 106两个片）造成不优化的再次分片
  • 最好的解决方式是让bsdi回送MTU，Solaris根据这个MTU采取最优化的分片

UDP和ARP之间的交互作用

1
2
bsdi % arp -a验证ARP高速缓存是空的
bsdi % sock -u -i -l -w8192 svr4 discard

  • 1.在第一个ARP应答返回以前，总共产生了6个ARP请求
  • 2.在接收第一个ARP应答时（第7行），只发送最后一个数据报片（第9行）
  • 3.在大多数的实现中，在等待一个ARP应答时，只将最后一个报文发送给特定目的主机
  • 4.另一个无法解释的不正常的现象是，svr4发回7个，而不是6个ARP应答
  • 5.这里我们没有看到ICMP消息的原因有两个。首先，大多数从Berkeley派生的实现从不产生该差错！这些实现会设置定时器，也会在定时器溢出时将数据报片丢弃，但是不生成ICMP差错
  • 6.第二，并未接收到包含UDP首部的偏移量为0的第一个数据报片（这是被ARP所丢弃的5个报文的第一个）除非接收到第一个数据报片，否则并不要求任何实现产生ICMP差错

最大UDP数据报长度

  • IP数据报的最大长度是65535字节，这是由IP首部16比特总长度字段所限制的
  • 我们将遇到两个限制因素，第一，应用程序可能会收到其程序接口的限制。Socket API提供了一个可供应用程序调用的函数，以设置接收和发送缓存的长度。对于UDP socket，这个长度与应用程序可以读写的最大UDP数据报的长度直接相关。现在的大部分系统都默认提供了可读写大于8192字节的UDP数据报（使用这个默认值是因为8192是NFS读写用户数据数的默认值）
  • 第二个限制来自于TCP|IP的内核实现。可能存在一些实现特性（或差错），使IP数据报长度小于65535字节
  • 在SunOS4.1.3下使用环回接口的最大IP数据报长度是32767字节。比它大的值都会发生差错。但是从BSD/386到SunOS4.1.3的情况下，Sun所能接收到最大IP数据报长度为32786字节（即32758字节用户数据）。在Solaris2.2下使用环回接口，最大可收发IP数据报长度为65535字节。从Solaris2.2到AIX3.2.2,发送的最大IP数据报长度可以是65535字节。很显然，这个限制和源端和目的端的实现有关
  • 要求主机必须能够接收最短为576字节的IP数据报，在许多的UDP应用程序的设计中，其应用数据被限制成512字节或更小，因此比这个限制值小

ICMP源站抑制差错

当一个系统（路由器或主机）接收数据报的速度比其处理速度快时，可能产生这个差错。

注意：“可能”产生这个差错。即使一个系统已经没有缓存并丢弃数据报，也不要求它一定要发送源站抑制报文。

UDP服务器的设计

对于服务器来说，它启动后处于休眠状态，等待客户请求的到来。对于UDP来说，当客户数据报到达时，服务器苏醒过来，数据报中可能包含来自客户的某种形式的请求消息。

  • （1）客户IP地址及端口号
    IP首部包含源端和目的端IP地址，UDP首部包含了源端和目的端的UDP端口号。当一个应用程序接收到UDP数据报时，操作系统必须告诉它是谁发送了这份消息，即源IP地址和端口号。这个特性允许一个交互UDP服务器对多个客户进行处理。给每个发送请求的客户发回应答。

  • （2）目的IP地址
    一些应用程序需要知道数据报是发送给谁的，即目的IP地址。这要求操作系统从接收到的UDP数据报中将目的IP地址交给应用程序。

  • （3）UDP输入队列
    大多数UDP服务器是交互服务器。这意味着，单个服务器进程对单个UDP端口上（服务器上的名知端口）的所有客户请求进行处理。

通常程序所使用的每个UDP端口都与一个有限大小的输入队列相联系。来自不同客户的差不多同时到达的请求将由UDP自动排队。接收到的UDP数据报以其接收顺序交给应用程序

排队溢出造成内核中的UDP模块丢弃数据报的可能性是存在的。

1）应用程序并不知道其输入队列何时溢出。只是由UDP对超出数据报进行丢弃处理。

2）没有发回任何信息告诉客户其数据报被丢弃。

  • （4）限制本地IP地址
    大多数UDP服务器在创建UDP端点时都使其本地IP地址具有通配符(wildcard)的特点。表明进入的UDP数据报如果其目的地为服务器端口，那么在任何本地接口均可接收到它。

另一方面，当服务器创建端点时，它可以把其中一个主机本地IP地址包括广播地址指定为端点的本地IP地址。只有当目的IP地址与指定的地址相匹配时，进入的UDP数据报才能被送到这个端点。

  • （5）限制远端IP地址

大多数系统都允许UDP端点对远端地址进行限制，即端点将只能接收特定IP地址和端口号的UDP数据报。

  • （6）每个端口有多个接收者

大多数系统在某一时刻只允许一个程序端点与某个本地IP地址及UDP端口号相关联。当目的地为该IP地址及端口号的UDP数据报到达主机时，就复制一份传给该端点。

然而，在一个支持多播的系统上，多个端点可以使用同一个IP地址和UDP端口号。

当UDP数据报到达的目的IP地址为广播地址或多播地址，而且在目的IP地址和端口号处有多个端点时，就向每个端点传送一份数据报的复制。如果UDP数据报到达的是一个单播地址，那么只向其中一个端点传送一份数据报的复制。选择哪个端点传送数据取决于各个不同的系统实现。

广播与多播

  • 三种IP地址：单播地址、广播地址和多播地址。
  • 广播和多播仅应用于UDP，它们对需要将报文同时传往多个接收者的应用来说十分重要
  • TCP是一个面向连接的协议，它意味着分别运行于两主机（由IP地址确定）内的两进程（由端口号确定）间存在一条连接
  • 有时一个主机要向网上的所有其他主机发送帧，这就是广播。通过ARP和RARP可以看到这一过程
  • 多播处于单播和广播之间：帧仅传送给属于多播组的多个主机

协议栈各层对收到帧的过滤过程

  • 网卡查看帧，确定是否接收该帧，若接收后将它传递给设备驱动程序。网卡仅接收目的地址为网卡物理地址或广播地址的帧。如果多接口设置为混合模式，能接收每个帧的一个复制；
  • 设备驱动程序将进行另外的帧过滤：
    1）帧类型中必须指定要使用的协议；
    2）进行多播过滤来检测该主机是否属于多播地址说的多播组
  • 设备驱动程序将数据帧传递给IP层（如果为IP类型的数据报）。IP根据IP地址中源地址和目的地址进行更多的过滤检测。如果正常，将数据报传递给下一层；
  • UDP根据IP层传递数据中目的端口来进行过滤。

广播

  • 受限的广播255.255.255.255
  • 指向网络的广播10.255.255.255 192.168.1.255
  • 指向子网的广播10.11.255.10.1.255.255
  • 指向所有子网的广播10.255.255.255
  • 主机处理的地址192.168.255.255（cisco路由器支持）
  • 路由器支持255.255.255.255，主机不支持（当主机处理）

多播

IP多播提供两类服务：

  • 向多个目的地址发送数据；
  • 客户对服务器的请求。

多播组地址

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

多播组地址到以太网地址的转换

  • IANA拥有一个以太网地址块，即高位24bit为00:00:5e（十六进制表示），这意味着该地址块所拥有的地址范围从00:00:5e:00:00:00到00:00:5e:ff:ff:ff。IANA将其中的一半（高位的第四个字节的高四位分成0~7和8~f两半，这样是分成了整体的一半）分配为多播地址。为了指明一个多播地址，任何一个以太网地址的首字节必须是01，这意味着与IP多播相对应的以太网地址范围从01:00:5e:00:00:00到01:00:5e:7f:ff:ff（7f这个就是一半）。
  • 由于7的二进制是0111，所以高位0是确定的了，因此以太网地址的前三个字节01:00:5e和下一位0确定了25bit。剩下的23bit和IP地址的低23bit相同。这样D类地址中高9bit中的低5bit就被忽略了。 –这样带来一个问题，5bit被忽略，那么表示会有32（2的5次方）个不同的多播号映射成了相同的以太网地址…比如：224.128.64.32和224.0.64.32都映射为同一以太网地址01:00:5e:00:40:20。
  • 既然地址映射是不唯一的，那么设备驱动程序或IP层就必须对数据报进行过滤。因为网卡可能接收到主机不想接收的多播数据帧。另外，如果网卡不提供足够的多播数据帧过滤功能，设备驱动程序就必须接收所有多播数据帧，然后对它们进行过滤。

IGMP：Internet组管理协议

  • IGMP协议让一个物理网络上的所有系统知道主机当前所在的多播组。多播路由器需要这些信息以便知道多播数据报应该向哪些接口转发。
  • 正如ICMP一样，IGMP也被当作IP层的一部分。IGMP报文通过IP数据报进行传输。不像我们已经见到的其他协议，IGMP有固定的报文长度，没有可选数据

IGMP报文

  • 这是版本为1的IGMP。IGMP类型为1说明是由多播路由器发出的查询报文，为2说明是主机发出的报告报文（多播路由器发出的是查询类型的报文，网络上的主机发送的是报告类型的报文）。检验和的计算和IGMP协议相同，同样覆盖首部和数据部分。
  • 组地址为D类IP地址。在查询报文中组地址设置为0，在报告报文中组地址为要参加的组地址。

IGMP报告和查询

多播路由器使用IGMP报文来记录与该路由器相连网络中组成员的变化情况。使用规则如下：

  • 当第一个进程加入一个组时，主机就发送一个IGMP报告。如果一个主机的多个进程加入同一组，只发送一个IGMP报告。这个报告被发送到进程加入组所在的同一接口上。
  • 进程离开一个组时，主机不发送IGMP报告，即便是组中的最后一个进程离开。主机知道在确定的组中已不再有组成员后，在随后收到的IGMP查询中就不再发送报告报文。
  • 多播路由器定时发送IGMP查询来了解是否还有任何主机包含有属于多播组的进程。多播路由器必须向每个接口发送一个IGMP查询。因为路由器希望主机对它加入的每个多播组均发回一个报告，因此IGMP查询报文中的组地址被设置为0。
  • 主机通过发送IGMP报告来响应一个IGMP查询，对每个至少还包含一个进程的组均要发回IGMP报告。

使用这些查询和报告报文，多播路由器对每个接口保持一个表，表中记录接口上至少还包含一个主机的多播组（多播路由只关心是不是至少有一个，有一个就得转发）。当路由器收到要转发的多播数据报时，它只将该数据报转发到（使用相应的多播链路层地址）还拥有属于那个组主机的接口上。

如图：查询和报告的报文。显示了两个IGMP报文，一个是主机发送的报告，另一个是路由器发送的查询。该路由器正在要求那个接口上的每个主机说明它加入的每个多播组

实现细节

实现IGMP的几个细节：

  • 当一个主机首次发送IGMP报告（当第一个进程加入一个多播组）时，并不保证该报告被可靠接收（因为使用的是IP交付服务）。下一个报告将在间隔一段时间后发送。这个时间间隔由主机在 0 ~ 1 0秒的范围内随机选择。
  • 当一个主机收到一个从路由器发出的查询后，并不立即响应，而是经过一定的时间间隔后才发出一些响应s（一个主机可能不止一个多播组，有几个就要发送几个响应）。

DNS：域名系统

引言

域名系统（DNS）是一种用于TCP/IP应用程序的分布式数据库，它提供主机名字和IP地址之间的转换及有关电子邮件的选路信息。

DNS基础

  • DNS的名字空间和Unix的文件系统相似，也具有层次结构
  • 每个结点（图14-1中的圆圈）有一个至多63个字符长
  • 以点“.”结尾的域名称为绝对域名或完全合格的域名FQDN(Full Qualified Domain Name)

  • 顶级域名被分为三个部分：
    1）arpa是一个用做地址到名字转换的特殊域
    2）7个3字符长的普通域，也称组织域
    3）所有2字符长的域均是基于ISO3166中定义的国家代码，这些域称为国家域，或地理域

  • 一个独立管理的DNS子树称为一个区域（zone）

  • DNS的一个基本特征是使用超高速缓存。即当一个名字服务器收到有关映射的信息（主机名字到IP地址）时，它会将该信息存放在高速缓存中。这样若以后遇到相同的映射请求，就能直接使用缓存中的结果而不需通过其他服务器查询

DNS的报文格式

DNS定义了一个用于查询和响应的报文格式。

  • 这个报文由12字节长的首部和4个长度可变的字段组成
  • 标识字段由客户程序设置并有服务器返回结果。客户程序通过它来确定响应与查询是否匹配
  • 16bit的标志字段被划分为若干子字段

    1）QR是1bit字段：0表示查询报文，1表示响应报文
    2）opcode是一个4bit字段：通常值为0（标准查询），其他值为1（反向查询）和2（服务器状态请求）
    3）AA是1bit标志，表示“授权回答”。该名字服务器是授权于该域的
    4）TC是1bit字段，表示“可截断的”。使用UDP时，它表示当应答的总长度超过512字节时，只返回前512个字节
    5）RD是1bit字段表示“期望递归”。该比特能在一个查询中设置，并在响应中返回。这个标志告诉名字服务必须处理这个查询，也称为一个递归查询。
    6）RA是1bit字段，表示“可用递归”。如果名字服务器支持递归查询，则在响应中该比特设置为1.
    7）随后的3bit字段必须为0
    8）recode是一个4bit的返回码字段。通常的值为0（没有差错）和3（名字差错）。名字差错只有从一个授权名字服务器上返回，它表示在查询中指定的域名不存在
    9）随后的4个16bit字段说明最后4个变长字段中包含的条目数。对于查询报文，问题数通常为1，而其他3项则均为0.

DNS查询报文中的问题部分

问题部分中每个问题的格式如图14-5所示，通常只有一个问题

  • 查询名是要查找的名字，它是一个或多个标识符的序列。每个标识符以首字节的计数值来说明随后标识符的字节长度，每个名字以最后字节为0结束，长度为0的标识符是根标识符。计数字节的值必须是0-63的数，因为标识符最大长度仅为63.
  • 每个问题有一个查询类型，而每个响应（也称一个资源记录）也有一个类型。

  • 最常用的查询类型是A类型，表示期望获得查询名的IP地址。一个PTR查询则请求获得一个IP地址对应的域名
  • 查询类通常是1，指互联网地址

DNS响应报文中的资源记录部分

DNS报文中最后的是三个字节，回答字段、授权字段和附加信息字段，均采用一种称为资源记录RR的相同格式。

  • 域名是记录中资源数据对应的名字
  • 类型说明RR的类型码。它的值和查询类型值是一样的，类通常为1，值Internet数据
  • 生成时间字段是客户程序保留该资源记录的秒数，通常的生成时间自为2天
  • 资源数据长度说明资源的数量

指针查询

  • 即给定一个IP地址，返回与该地址对应的域名
  • 查询结果包含一个回答RR，且为授权回答比特置1.RR的类型是PTR，资源数据中包含该域名

主机名检查

当一个IP数据报到达一个作为服务器的主机时，无论是UDP数据报还是TCP连接请求，服务器进程所能获得的是客户的IP地址和端口号（UDP和TCP）。

资源记录

资源记录（RR）：IP地址查询为A类型，指针查询为类型FTR。由名字服务器返回的资源记录：回答RR、授权RR和附加信息RR。现有大约20种不同类型的资源记录。

  • A：一个A记录定义了一个IP地址，它存储32bit的二进制数
  • PTR：指针记录用于指针查询
  • CNAME：这表示“规范名字（canonical name）”。它用来表示一个域名，而有规范名字的域名通常被称为别名
  • HINFO:表示主机信息：包括说明主机CPU和操作系统的两个字符串。并非所有的站点均提供它们系统的HINFO记录，并且提供的信息也可能不是最新的
  • MX:邮件交换记录
  • NS:名字服务器记录

高速缓存

  • 为了减少Internet上DNS的通信量，所有的名字服务器均使用高速缓存。
  • 在标准的Unix实现中，高速缓存是由名字服务器而不是由名字解析器维护的。

TFTP：简单文件传送协议

引言

  • TFTP（Trivial File Transfer Protocol）即简单文件传送协议，最初打算用于引导无盘系统
  • TFTP使用UDP
  • TFTP的代码（和它需要的UDP、IP和设备驱动程序）都能适合只读存储器

协议

  • 在开始工作时，T F T P的客户与服务器交换信息，客户发送一个读请求或写请求给服务器。在一个无盘系统进行系统引导的正常情况下，第一个请求是读请求（ R R Q）。
  • T F T P报文的头两个字节表示操作码。对于读请求和写请求（ W R Q），文件名字段说明客户要读或写的位于服务器上的文件。这个文件字段以 0字节作为结束（见图 1 5 - 1）。模式字段是一个A S C I I码串n e t a s c i i或o c t e t（可大小写任意组合），同样以0字节结束。n e t a s c i i表示数据是以成行的A S C I I码字符组成，以两个字节 — 回车字符后跟换行字符（称为C R / L F）作为行结束符。
  • 每个数据分组包含一个块编号字段，它以后要在确认分组中使用。
  • 在写请求的情况下，TFTP 客户发送W R Q指明文件名和模式。如果该文件能被 该客户写，TFTP 服务器就返回块编号为 0的A C K包。该客户就将文件的头 5 1 2字节以块编号为1发出。服务器则返回块编号为1的A C K。这种类型的数据传输称为停止等待协议。

  • 最后一种T F T P报文类型是差错报文，它的操作码为 5。它用于服务器不能处理读请求或写请求的情况。在文件传输过程中的读和写差错也会导致传送这种报文，接着停止传输。差错编号字段给出一个数字的差错码，跟着是一个 A S C I I表示的差错报文字段，可能包含额外的操作系统说明的信息。
  • 既然T F T P使用不可靠的U D P，T F T P就必须处理分组丢失和分组重复。分组丢失可通过发送方的超时与重传机制解决（注意存在一种称为“魔术新手综合症 ( s o r c e r e r’s apprentices y n d r o m e )”的潜在问题，如果双方都超时与重传，就可能出现这个问题。

安全性

  • 在T F T P分组（图1 5 - 1）中并不提供用户名和口令。这是 T F T P的一个特征（即“安全漏洞”）。由于T F T P是设计用于系统引导进程，它不可能提供用户名和口令。
  • 目前大多数 T F T P服务器提供了一个选项来限制只能访问特定目录下的文件（U n i x系统中通常是/ t f t p b o o t）。这个目录中只包含无盘系统进行系统引导时所需的文件

BOOTP：引导程序协议

引言

  • 无盘系统在不知道自身IP地址的情况下，在进行系统引导时能够通过RARP来获取它的IP地址。然而使用RARP有两个问题：（1）I P地址是返回的唯一结果；（2）既然R A R P使用链路层广播， R A R P请求就不会被路由器转发（迫使每个实际网络设置一个RARP 服务器）
  • BOOTP（引导程序协议）是一种用于无盘系统进行系统引导的替代方法
  • BOOTP使用UDP，且通常需与TFTP协同工作

BOOTP的分组格式

BOOTP 请求和应答均被封装在U D P数据报中，如图1 6 - 1所示。

图1 6 - 2显示了长度为3 0 0字节的B O O T P请求和应答的格式。

  • “操作码”字段为1表示请求，为2表示应答。硬件类型字段为 1表示10 Mb/s的以太网
  • “跳数”字段由客户设置为0，但也能被一个代理服务器设置
  • “事务标识”字段是一个由客户设置并由服务器返回的 32 bit整数。客户用它对请求和应答进行匹配。对每个请求，客户应该将该字段设置为一个随机数。
  • 客户开始进行引导时，将“秒数”字段设置为一个时间值。服务器能够看到这个时间值，备用服务器在等待时间超过这个时间值后才会响应客户的请求，这意味着主服务器没有启动。
  • 如果该客户已经知道自身的 I P地址，它将写入“客户 I P地址”字段。否则，它将该字段设置为0。对于后面这种情况，服务器用该客户的 I P地址写入“你的 I P地址”字段。“服务器I P地址”字段则由服务器填写。如果使用了某个代理服务器（见 1 6 . 5节），则该代理服务器就填写“网关I P地址”字段。
  • 客户必须设置它的“客户硬件地址”字段。尽管这个值与以太网数据帧头中的值相同，U D P数据报中也设置这个字段，但任何接收这个数据报的用户进程能很容易地获得它（例如一个BOOTP 服务器）。一个进程通过查看U D P数据报来确定以太网帧首部中的该字段通常是很困难的（或者说是不可能的）。
  • “服务器主机名”字段是一个空值终止串，由服务器填写。服务器还将在“引导文件名字段”填入包括用于系统引导的文件名及其所在位置的路径全名。
  • “特定厂商区域”字段用于对B O O T P进行不同的扩展。

端口号

B O O T P有两个熟知端口：BOOTP 服务器为6 7，BOOTP 客户为6 8。

TCP：传输控制协议

TCP的服务

  • TCP提供一种面向连接的、可靠的字节流服务
  • 面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之间必须先建立一个TCP连接
  • 在一个TCP连接中，仅有两方进行彼此通信

TCP通过下列方式来提供可靠性

  • 应用数据被分隔成TCP认为最适合发送的数据块
  • 当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段
  • 当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒
  • TCP将保持它首部和数据的检验和
  • 既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层
  • 既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据
  • TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出

TCP的字节流

  • 两个应用程序通过TCP连接交换8 bit构成的字节流。TCP不在字节流中插入记录标识符。将这称为字节流服务。
  • 假设一方的应用程序先传10字节，又传20字节，再传50字节，连接的另一方将无法了解发方每次发送了多少字节。收方可以分4次接收这80个字节，每次接收20字节。
  • TCP对字节流的内容不作任何解释，它不知道传输的数据字节流是二进制数据、ASCII字符、EBCDIC字符或其他类型数据。由TCP双方的应用层对字节流进行解释。

TCP的首部

TCP数据被封装在一个IP数据报中

  • 每个TCP段都包含源端和目的端的端口号，用于寻找发端和收端应用进程。这两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接
  • 一个IP地址和一个端口号也称为一个插口（socket）。插口对（socket pair）（包含客户IP地址、客户端口号、服务器IP地址和服务器端口号的四元组）可唯一确定互联网网络中每一个TCP连接的双方
  • 序号用来标识从TCP发端向收端发送的数据字节流。如果将字节流看作是在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。序号是32 bit的无符号数，到达2^32-1后又从0开始。SYN标志消耗了一个序号
  • 因为每个传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号，即确认序号是上次已成功收到数据字节序号加1。只有ACK标志为1时确认序号字段才有效
  • 发送ACK无需占用任何序号，因为32 bit的确认序号字段和ACK标志一样，总是TCP首部的一部分。因此，一旦一个连接建立起来，这个字段总是被设置，ACK标志也总是被设置为1。
  • 首部长度给出首部中32 bit字的数目。需要这个值是因为任选字段的长度是可变的。这个字段占4 bit，因此TCP最多有60字节的首部（32bit*(2^4-1)）。如果没有选项字段，正常的长度是20字节。
  • TCP为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据序号
  • TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端期望接收的字节。窗口大小是一个16 bit字段，因而窗口大小最大为65535字节。
  • 检验和覆盖了整个TCP报文段包括TCP首部和TCP数据。这是一个强制性的字段，一定是由发端计算和存储，并由收端进行验证。
    说明：TCP检验和的计算与UDP检验和的计算相似，使用一个伪首部。
  • 只有当URG标志置1时紧急指针才有效。紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。
  • 最常见的选项字段是最长报文大小，又称为MSS (Maximum Segment Size)。每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志的那个段）中指明这个选项。它指明本端所能接收的最大长度的报文段。
  • TCP报文段中的数据部分是可选的。例如：一个连接建立和终止时，双方交换的报文段仅有TCP首部。在处理超时的许多情况中，也会发送不带任何数据的报文段。

TCP首部中有6个标志比特

可同时多个被设置为1

  • URG 紧急指针有效
  • ACK 确认序号有效
  • PSH 接收方应该尽快将这个报文段交给应用层
  • PST 重建连接
  • SYN 同步序号用来发起一个连接。
  • FIN 发端完成发送任务

TCP连接的建立与终止

引言

  • TCP是一个面向连接的协议。无论哪一方向另一方发送数据之前，都必须先在双方之间
    建立一条连接。本章将详细讨论一个 T C P连接是如何建立的以及通信结束后是如何终止的。
  • 这种两端间连接的建立与无连接协议如 U D P不同。我们在第 11章看到一端使用U D P向另
    一端发送数据报时，无需任何预先的握手。

建立连接协议

建立连接协议

如18-3所示，为了建立一条TCP连接：

  • 请求端（客户）发送一个SYN段指明客户打算连接的服务器的端口，以及初始序号（ISN，例子中为1415531521），如报文1。
  • 服务器发回包含服务器的初始序号的SYN报文段（报文段2）作为应答。同时，将确认序号设置为客户的ISN加1以对客户的SYN报文段进行确认。一个SYN将占用一个序号。
  • 客户必须将确认序号设置为服务器的ISN加1以对服务器的SYN报文段进行确认（报文段3）。

这三个报文段完成连接的建立，这个过程也称为三次握手。

说明：

  • 发送第一个SYN的一端将执行主动打开，接收这个SYN并发回下一个SYN的另一端执行被动打开。

  • 当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。

终止连接

终止一个连接要经过4次握手。这是由TCP的半关闭造成的。
说明：

  • 因为TCP是全双工的（数据在两个方向上能同时传递），因此每个方向必须单独进行关闭。原则是：当一方完成它的数据发送任务后发送一个FIN来终止这个方向连接。当一端收到一个FIN时，它必须通知应用层另一端已经终止了那个方向的数据传送。

注意：发送FIN通常是应用层进行关闭的结果。

  • 收到一个FIN只意味着在这一方向上没有数据流动。

注意：一个TCP连接在收到一个FIN后仍能发送数据，这对利用半关闭的应用来说是可能的，尽管在实际应用中只有很少的TCP应用程序这样做。

图18-4显示了终止一个连接的典型握手顺序。

发送FIN将导致应用程序关闭它们的连接，这些FIN的ACK是由TCP软件自动产生的。

最大报文段长度

  • 最大报文段长度（MSS）表示TCP传往另一端的最大块数据的长度。当一个连接建立时，连接的双方都要通告各自的MSS。
  • 当建立一个连接时，每一方都有用于通告它期望接收的MSS选项（MSS选项只能出现在SYN报文段中）。如果一方不接收来自另一-* 方的MSS值，则MSS就定为默认值536字节（这个默认值允许20字节的IP首部和20字节的TCP首部以适合576字节IP数据报。

注意：

（1）一般说来，如果没有分段发生，MSS越大越好。报文段越大允许每个报文段传送的数据就越多，相对IP和TCP首部有更高的网络利用率。

（2）当TCP发送一个SYN时，或者是因为一个本地应用进程想发起一个连接，或者是因为另一端的主机收到了一个连接请求，它能将MSS值设置为外出接口上的MTU长度减去固定的IP首部和TCP首部长度。

（3）如果目的IP地址为“非本地的(non-local)”，MSS通常的默认值为536。

说明：区分地址是本地还是非本地的方法是：如果目的IP地址的网络号与子网号都与本机相同，则是本地的；如果目的IP地址的网络号与本机相同而子网号不同，则可能是本地的，也可能是非本地的。

（4）MSS使得主机限制另一端发送数据报的长度。加上主机也能控制它发送数据报的长度，这使得以较小MTU连接到一个网络上的主机避免分段。


主机sun向slip发起一个TCP连接，利用tcpdump命令来观察报文段：

说明：

（1）sun发送的报文段不能超过256字节的数据，因为slip已经告知它的MSS值为256。（上图第二个红框）

（2）slip知道它外出接口的MTU长度为296，所以即使sun已经告诉它的MSS为1460（上图第一个红框），但为避免将数据分段，它不会发送超过256字节数据的报文段。

（
3）如果两端主机都连接到以太网上，都采用536的MSS，但中间网络采用296的MTU，同样会出现分段。

TCP的半关闭

TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力，即半关闭。

注意：很少有应用程序使用它，如果想要使用这个功能，需要编程接口提供一个方式来说明。

下面给出一个例子：

意思是这样的：客户结束了发送数据（发送了FIN），服务器发送ACK表示确认后，仍然可以发送数据给客户（图中红框）。

TCP的状态变迁图

2MSL等待状态

TIME_WAIT状态也称为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL（Maximum Segment Lifetime）。它是任何报文段被丢弃前在网络内的最长时间。

注意：MSL是个有限的时间，我们知道TCP报文段以IP数据报在网络中传输，IP数据报是由TTL字段限制其生存时间的。RFC 793指出MSL为2分钟。实现中的常用值是30秒，1分钟，或2分钟。

对于给定的MSL值，原则是：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失（另一端超时并重发最后的FIN）。

说明：

1）客户执行主动关闭并进入TIME_WAIT是正常的。服务器通常执行被动关闭，不会进入TIME_WAIT状态。

2）TCP连接在2MSL等待期间，这个连接的socket（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用。这个连接只能在2MSL结束后才能再被使用。

平静时间的概念

如果处于2MSL等待端口的主机出现故障，它会在MSL秒内重新启动，并立即使用故障前处于2MSL的socket来建立一个新的连接。在故障前从这个连接发出而迟到的报文段会被错误地当作属于重启后新连接的报文段。

为了防止这种情况，RFC 793指出TCP在重启动后的MSL秒内不能建立任何连接，称为平静时间(quiet time)。

FIN_WAIT_2状态

如上面的图所示：FIN_WAIT_2状态时，客户已经发出了FIN，另一端也已对它进行确认。

除非客户设置了半关闭，否则将等待另一端的应用层意识到它已收到一个文件结束符说明，并向我们发一个FIN 来关闭连接。只有这样，我们这端才会从FIN_WAIT_2状态进入TIME_WAIT状态。

复位报文段

TCP首部中的RST比特是用于“复位”的，一般无论何时一个报文段发往“基准连接”出现错误，TCP都会发出一个复位报文段。

说明：“基准连接”是指由目的IP地址和端口号以及源IP地址和端口号指明的连接。

到不存在的端口的连接请求

产生复位的一种常见情况是当连接请求到达时，目的端口没有进程正在听。

注意：对于UDP，当一个数据报到达目的端口时，该端口没在使用，它将产生一个ICMP端口不可达的信息；对于TCP，则使用复位。

图中的意思是说：主机bsdi向svr4的20000端口发送SYN，然后svr4告诉bsdi一个复位连接的信息。

异常终止一个连接

终止一个连接的正常方式是一方发送FIN。这也称为有序释放，因为在所有排队数据都已发送之后才发送FIN，正常情况下没有任何数据丢失。但也有可能发送一个复位报文段而不是FIN来中途释放一个连接。这也称为为异常释放。

异常终止一个连接对应用程序来说有两个优点：

1）丢弃任何待发数据并立即发送复位报文段；

2）RST的接收方会区分另一端执行的是异常关闭还是正常关闭。

特别注意：RST报文段不会导致另一端产生任何响应，另一端根本不进行确认。收到RST的一方将终止该连接，并通知应用层连接复位。

检测半打开连接

如果一方已经关闭或异常终止连接而另一方却还不知道，将这样的TCP连接称为半打开的。

说明：

1）任何一端的主机异常都可能导致半打开连接。只要不在半打开连接上传输数据，仍处于连接状态的一方就不会检测到另一方已经出现异常。

2）半打开连接的另一个常见原因是当客户主机突然掉电而不是正常的结束客户应用程序后再关机。

同时打开

两个应用程序同时彼此执行主动打开的情况是可能的，尽管发生的可能性极小。每一方必须发送一个SYN，且这些SYN必须传递给对方。这需要每一方使用一个对方熟知的端口作为本地端口，称为同时打开。

TCP对于同时打开仅建立一条连接而不是两条连接。当出现同时打开时：

两端几乎同时发送SYN，并进入SYN_SENT状态。当每一端收到SYN时，状态变为SYN_RCVD，同时它们都再发SYN并对收到的SYN进行确认。当双方都收到SYN及相应的ACK时，状态都变迁为ESTABLISHED。

注意：

（1）一个同时打开的连接需要交换4个报文段，比正常的三次握手多一个。

（2）对于同时打开的连接，我们没有将任何一端称为客户或服务器，因为每一端既是客户又是服务器。

同时关闭

双方都执行主动关闭也是可能的，TCP也允许同时关闭。

同时关闭过程为：

（1）当应用层发出关闭命令时，两端均从ESTABLISHED变为FIN_WAIT_1。这将导致双方各发送一个FIN，两个FIN经过网络传送后分别到达另一端。

（2）收到FIN后，状态由FIN_WAIT_1变为CLOSING，并发送最后的ACK。

（3）当收到最后的ACK时，状态变化为TIME_WAIT。

注意：同时关闭和正常关闭报文段交换数目相同。

TCP选项

TCP首部可以包含选项部分。

选项说明：

（1）每个选项的开始是1字节kind字段，说明选项的类型。

（2）kind字段为0和1的选项仅占1个字节。其他选项在kind字节后还有len字节，它说明的长度是指总长度，包括kind字节和len字节。

（3）设置无操作选项的原因在于允许发方填充字段为4字节的倍数。

TCP的交互数据流

引言

有关TCP通信量的研究发现：按分组数量计算，约有一半的TCP报文段包含成块数据（如FTP、电子邮件和Usenet新闻），另一半则包含交互数据（如Telnet和Rlogin）。按字节计算，成块数据与交互数据的比例约为90%和10%。

成块数据的报文段基本上都是满长度的（通常为512字节的用户数据），交互数据则小得多（Telnet和Rlogin分组中约90%左右的用户数据小于10个字节）

TCP需要同时处理这两类数据，但使用的处理算法不同。

交互式输入

说明：本书是以远程登录Rlogin协议模拟交互输入的，我没有进行相关实验，下面我会给出作者所做的实验截图。

如图19-1所示，Rlogin协议需要远程系统回显客户输入的字符，每按一个字符就会产生一个分组，而不是每次一行作为一个分组。

一般可以将报文段2和3合并（图中两个红框）

当我们键入5个字符date\n时的数据流，如图19-2所示：

说明：

（1）第1行：客户发送字符d到服务器；第2行：该字符的确认及回显；第3行：回显字符的确认。

（2）与字符a有关的是第4~6行，与字符t有关的是第7~9行，与字符e有关的是第10~12行。

（3）13~15行与上面稍有不同。客户发送到服务器的是一个字符（换行符），而回显的是两个字符（图中14行红线处），这两个字符为：回车和换行字符，作用是将光标移动到左边并换到下一行。

（4）第16行：来自服务器date命令的输出。这30个字节（图中红线处）由28个字符与最后的回车+换行组成。第17、18行：服务器发往客户7个字符（第18行），它们是在服务器主机上的客户提示符：svr4%。第19行：确认了这7个字符。

经受时延的确认

图19-3表示了图19-2中数据交换的时间。

通常TCP在接收到数据时并不立即发送ACK；它会推迟发送，以便将ACK与需要沿该方向发送的数据一起发送，有时称这种现象为数据捎带ACK。

说明：绝大多数实现采用的时延为200ms，即TCP将以最大200ms的时延等待是否有数据一起发送。

下面我假设你会看这张图中标记的时间差，会计算实际时间（累加）。说明如下：

观察bsdi接收到数据和发送ACK之间的时间差：123.5、65.6、109.0、132.2、42.0、140.3和195.8 ms，似乎是随机的。观察bsdi发送ACK的实际时间（从0开始计算）为：139.9、539.3、940.1、1339.9、1739.9、1940.1和2140.1 ms，这些时间差是200ms的整数倍。

注意：因为TCP使用了一个200ms的定时器，以相对于内核引导的200ms固定时间溢出。由于将要确认的数据是随机到达的，TCP在内核的200ms定时器的下一次溢出时得到通知。

Nagle算法

Rlogin连接时，一般每次发送一个字节到服务器，这就产生了一些41字节长的分组：20字节的IP首部、20字节的TCP首部和1个字节的数据。

在局域网上，这些小分组（被称为微小分组tinygram）通常不会引起麻烦，因为局域网一般不会出现拥塞。在广域网上，这些小分组则会增加拥塞出现的可能。一种简单有效的方法就是采用RFC 896建议的Nagle算法。

算法说明：

算法要求一个TCP连接上最多只能有一个未被确认的未完成的小分组，在该分组的确认到达之前不能发送其他的小分组。相反，TCP收集这些少量的分组，并在确认到来时以一个分组的方式发出去。

算法优点：

算法的优越之处在于它是自适应的：确认到达得越快，数据也就发送得越快。在希望减少微小分组数目的低速广域网上，则会发送更少的分组。

从图19-3中看到，在以太网上一个字节被发送、确认和回显的平均往返时间约为16ms。为了产生比这个速度更快的数据，我们每秒键入的字符必须多于60个。说明在局域网环境下两个主机之间发送数据时很少使用这个算法。

当往返时间（RTT）增加时，如通过一个广域网，情况发生了变化。如图19-4：

从左到右待发数据的长度是不同的，分别为：1、1、2、1、2、2、3、1和3个字节。这是因为客户只有收到前一个数据的确认后才发送已经收集的数据。通过使用Nagle算法，为发送16个字节的数据客户只需要使用9个报文段，而不再是16个。

关闭Nagle算法

有时我们也需要关闭Nagle算法。例如，X窗口系统服务器，小消息（鼠标移动）必须无时延地发送，以便为进行某种操作的交互用户提供实时的反馈。

窗口大小通告

观察图19-4，可以看到slip通告窗口大小为4096字节，vangogh通告其窗口大小为8192字节。但报文段5通告的窗口大小为4095个字节，意味着TCP缓冲区中仍然有一个字节等待应用程序（Rlogin客户）读取。

说明：

（1）通常服务器通告窗口大小为8192个字节，这是因为服务器在读取并回显接收到的数据之前，其TCP没有数据发送。当服务器已经读取了来自客户的输入后，来自服务器的数据将被发送。

（2）在ACK到来时，客户的TCP总是有数据需要发送。这是因为它在等待ACK的过程中缓存接收到的字符。当客户TCP发送缓存的数据时，Rlogin客户没有机会读取来自服务器的数据，因此，客户通告的窗口大小总是小于4096。

TCP的成块数据流

正常数据流

  • 通常使用的“隔一个报文段确认”的策略
  • 分组顺序依赖于许多无法控制的因素：发送方T C P的实现、接收方T C P的实现、接收进程读取数据（依赖于操作系统的调度）和网络的动态性（如以太网的冲突和退避等）。

快的发送方和慢的接收方

  • 发送方发送4个背靠背（b a c k - t o - b a c k）的数据报文段去填充接收方的窗口，然后停下来等待一个A C K。接收方发送A C K（报文段8），但通告其窗口大小为 0，这说明接收方已收到所有数据，但这些数据都在接收方的 T C P缓冲区，因为应用程序还没有机会读取这些数据。
  • 另一个A C K（称为窗口更新）在17.4 ms后发送，表明接收方现在可以接收另外的 4 0 9 6个字节的数据。虽然这看起来像一个 A C K，但由于它并不确认任何新数据，只是用来增加窗口的右边沿，因此被称为窗口更新。
  • 发送方发送最后4个报文段（1 0 ~ 1 3），再次填充了接收方的窗口。注意到报文段 1 3中包括两个比特标志：P U S H和F I N。随后从接收方传来另外两个 A C K，它们确认了最后的4 0 9 6字节的数据（从4 0 9 7到8 1 9 2字节）和F I N（标号为8 1 9 2）。

滑动窗口

  • 在这个图中，我们将字节从 1至11进行标号。接收方通告的窗口称为提出的窗口（ o ff e r e dw i n d o w），它覆盖了从第4字节到第9字节的区域，表明接收方已经确认了包括第 3字节在内的数据，且通告窗口大小为 6。回顾第1 7章，我们知道窗口大小是与确认序号相对应的。发送方计算它的可用窗口，该窗口表明多少数据可以立即被发送。

  • 当接收方确认数据后，这个滑动窗口不时地向右移动。窗口两个边沿的相对运动增加或减少了窗口的大小。使用三个术语来描述窗口左右边沿的运动：
    1) 称窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时。
    2) 当窗口右边沿向右移动时将允许发送更多的数据，我们称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了 T C P的接收缓存时。
    3) 当右边沿向左移动时，我们称之为窗口收缩。 Host Requirements RFC强烈建议不要使用这种方式。但T C P必须能够在某一端产生这种情况时进行处理

一个例子

以该图为例可以总结如下几点：
1) 发送方不必发送一个全窗口大小的数据。
2) 来自接收方的一个报文段确认数据并把窗口向右边滑动。这是因为窗口的大小是相对于确认序号的。
3) 正如从报文段7到报文段8中变化的那样，窗口的大小可以减小，但是窗口的右边沿却不能够向左移动。
4) 接收方在发送一个A C K前不必等待窗口被填满。在前面我们看到许多实现每收到两个报文段就会发送一个A C K。

PUSH标志

发送方使用该标志通知接收方将所收到的数据全部提交给接收进程。这里的数据包括与 P U S H一起传送的数据以及接收方T C P已经为接收进程收到的其他数据。

慢启动

  • 发送方一开始便向网络发送多个报文段，直至到达接收方通告的窗口大小为止。当发送方和接收方处于同一个局域网时，这种方式是可以的。但是如果在发送方和接收方之间存在多个路由器和速率较慢的链路时，就有可能出现一些问题。一些中间路由器必须缓存分组，并又可能耗尽存储器的空间，然后发生丢包
  • TCP采用“慢启动（slow start）”算法来降低一开始就发送过多的数据到网络
  • 慢启动为发送方的T C P增加了另一个窗口：拥塞窗口(congestion window)，记为c w n d。当与另一个网络的主机建立 T C P连接时，拥塞窗口被初始化为 1个报文段（即另一端通告的报文段大小）。每收到一个A C K，拥塞窗口就增加一个报文段（ c w n d以字节为单位，但是慢启动以报文段大小为单位进行增加）。发送方取拥塞窗口与通告窗口中的最小值作为发送上限。拥塞窗口是发送方使用的流量控制，而通告窗口则是接收方使用的流量控制。
  • 发送方开始时发送一个报文段，然后等待 A C K。当收到该A C K时，拥塞窗口从1增加为2，即可以发送两个报文段。当收到这两个报文段的 A C K时，拥塞窗口就增加为4。这是一种指数增加的关系。
  • 在某些点上可能达到了互联网的容量，于是中间路由器开始丢弃分组。这就通知发送方它的拥塞窗口开得过大。当我们在下一章讨论 T C P的超时和重传机制时，将会看到它们是怎样对拥塞窗口起作用的。现在，我们来观察一个实际中的慢启动。

发送一个分组的时间

  • 通常发送一个分组的时间取决于两个因素：传播时延和发送时延
  • 对于一个给定的两个接点之间的同路，传播时延一般是固定的，而发送时延则取决于分组大小
  • 在速率较慢的情况下发送时延起主要作用，而在千兆比特速率下传播时延则占主要地位

带宽时延乘积

  • 为了最大限度的利用链路带宽，必须确保发送发源源不断的收到接收方发送的ACK，做为收到数据的确认和更新window size的大小
  • 在开始阶段，通告的window size必须大于等于带宽和往返时延的乘积，才能确保在收到第一个ACK前，能够一直发送数据流量。因为发送第一个数据报文到收到对应的ACK，时间至少RTT时间
  • 计算通道的容量为：
    c a p a c i t y (bit) = b a n d w i d t h (b/s) × ro u n d-trip time ( s )

TCP的超时重传

T C P提供可靠的运输层。它使用的方法之一就是确认从另一端收到的数据。但数据和确认都有可能会丢失。 T C P通过在发送时设置一个定时器来解决这种问题。如果当定时器溢出时还没有收到确认，它就重传该数据

对每个连接，T C P管理4个不同的定时器。
1) 重传定时器使用于当希望收到另一端的确认。在本章我们将详细讨论这个定时器以及
一些相关的问题，如拥塞避免。
2) 坚持( p e r s i s t )定时器使窗口大小信息保持不断流动，即使另一端关闭了其接收窗口
3) 保活( k e e p a l i v e )定时器可检测到一个空闲连接的另一端何时崩溃或重启
4) 2MSL定时器测量一个连接处于 T I M E _ WA I T状态的时间。

FTP：文件传送协议

FTP简介

  • 数据传输主流协议
  • 两个信道
    • 第一信道，控制信道，无论何时都是由客户端发起连接。采用客户端服务器模式。服务端监听21端口。用于控制命令的传输。主要任务就是认证，控制命令（如查看文件列表等）等
    • 第二信道，数据信道。根据数据信道是否由服务端发起，区分ActiveMode和PassiveMode。数据的传输走的是第二信道，包括文件列表数据的传输。
    • TCP的知名端口号（服务端的监听端口），21号，是控制信道的端口。
  • FTP两个模式
    • Active Mode
    • Passive Mode

FTP命令

Active Mode

  • 第一信道通常三次握手建立FTP连接
  • 第二信道（数据信道），是由服务器主动发起的，即是ActiveMode。
  • 第二信道（数据通道），是服务器被动接收的，即是PassiveMode。
  • 可见，第二信道，即数据信道（传输数据而非控制命令），是由服务端主动发起的，即是主动模式（ActiveMode）；如果不是服务器主动发起的，即是被动模式（PassiveMode）。
  • 第一信道中，客户端向FTP服务器发送的数据中，含有PORT（a,b,c,d,e,f）这里a,b,c,d,e,f每上表示0~255的数据，其中a,b,c,d表示客户端的IP，e,f表示客户端的第二通道的端口（计算方法是：e*256+f）。这主要是为了供第二通道中，服务端主动发起向客户端的连接使用的。

安全性


注意：由于用户名和密码都是明文传输，易于被截获，因此，对于FTP来说，使用匿名登陆反而更安全。

List


客户端第二通道是IP和端口是： 202.100.1.100,4256+38
第一次传入PORT后，紧跟的是一个控制命令，LIST（查看列表）。
然后，服务端20号端口通过第二信道与客户端的4256+38端口建立连接，并传送文件列表。

Download


当单击文件列表中的一个文件，又出现了一个PORT发给服务端（注意这次的端口号有变化，4256+42），接着又发了一个RETR命令，后面跟着所请求的文件。
这时，服务端20号端口又通过第二信道与客户端4256+42端口建立连接，并传送该文件。（注意，与第一次不是同一个端口号，也就是说又建立了一次连接）
注意：这里是又建立了一次连接。

Passive Mode


第二信道，服务器被动接受为被动模式（PassiveMode）。
在第一信道中，客户端发送PASV命令，询问服务端是否支持被动模式。服务端回复227表示支持，这时a,b,c,d,e,f表示服务端第二信道的IP和端口。
目前一般使用的是PassiveMode模式，客户端连接后，一般会发PASV询问服务器是否支持PassiveMode，如果支持，则使用PassiveMode。

Telnet：远程登录

  • 1) Te l n e t客户进程同时和终端用户和T C P / I P协议模块进行交互。通常我们所键入的任何信息的传输是通过T C P连接，连接的任何返回信息都输出到终端上。
  • Te l n e t服务器进程经常要和一种叫做“伪终端设备”（pseudo-terminal device）打交道，至少在U n i x系统下是这样的。这就使得对于登录外壳 ( s h e l l )进程来讲，它是被Te l n e t服务器进程直接调用的，而且任何运行在登录外壳进程处的程序都感觉是直接和一个终端进行交互。
  • 仅仅使用了一条T C P连接。由于客户进程必须多次和服务器进程进行通信（反之亦然），这就必然需要某些方法，来描绘在连接上传输的命令和用户数据。

Telnet协议

Te l n e t协议可以工作在任何主机（例如，任何操作系统）或任何终端之间。

NVT ASCII

  • 术语NVT ASCII代表7比特的A S C I I字符集，网间网协议族都使用NVT ASCII。每个7比特的字符都以8比特格式发送，最高位比特为0。
  • 行结束符以两个字符 C R（回车）和紧接着的 L F（换行）这样的序列表示。以 \ r \ n来表示。单独的一个 C R也是以两个字符序列来表示，它们是 C R和紧接着的 N U L（字节0），以\ r \ 0表示。
  • F T P, SMTP, Finger和W h o i s协议都以NVT ASCII来描述客户命
    令和服务器的响应。

Telnet命令

Te l n e t通信的两个方向都采用带内信令方式。

一次一个字符方式

我们所键入的每个字符都单独发送到服务器进程。服务器进程回显大多数的字符，除非服务器进程端的应用程序去掉了回显功能。该方式的缺点也是显而易见的。当网络速度很慢，而且网络流量比较大的时候，那么回显的速度也会很慢。虽然如此，但目前大多数 Te l n e t实现都把这种方式作为默认方式。

Telnet协议两大特点

  • 交互式TCP数据流的特点
  • 安全问题（替代协议SSH）

SMTP/POP3：简单邮件传送协议/邮局协议版本3

SMTP简介

  • SMTP（Simple Mail Transfer Protocol）即简单邮件传输协议,它是一组用于由源地址到目的地址传送邮件的规则，由它来控制信件的中转方式。SMTP协议属于TCP/IP协议簇，它帮助每台计算机在发送或中转信件时找到下一个目的地。通过SMTP协议所指定的服务器,就可以把E-mail寄到收信人的服务器上了，整个过程只要几分钟。SMTP服务器则是遵循SMTP协议的发送邮件服务器，用来发送或中转发出的电子邮件。
  • SMTP 是一种TCP协议支持的提供可靠且有效电子邮件传输的应用层协议。SMTP 是建立在 TCP上的一种邮件服务，主要用于传输系统之间的邮件信息并提供来信有关的通知。[1]
  • 端口 25

SMTP协议的邮件路由过程

STMP服务器基于域名服务器DNS中计划收件人的域名来路由电子邮件。SMTP服务器基于DNS的MX记录来路由电子邮件，都应向该主机发送。若SMTP服务器mail.abc.com收到一封信要发到shuer@sh.abc.com，则执行以下过程：

  • Sendmail请求DNS给出主机sh.abc.com的CNAME记录，如有，假若CNAME（别名记录）到shmail.abc.com，则再次请求shmail.abc.com的CNAME的记录，直到没有为止
  • 假定被CNAME到shmail.abc.com，然后sendmail请求@abc.com域的DNS给出shmail.abc.com的MX记录（邮件路由及记录），shmail MX 5 shmail.abc.com 10 shmail2.abc.com
  • Sendmail组合请求DNS给出shmail.abc.com的A记录（主机名或域名对应的IP地址记录），即IP地址，若返回值为1.2.3.4（假设值）
  • Sendmail与1.2.3.4连接，传送这封给shuser@sh.abc.com的信到1.2.3.4这台服务器的SMTP后台程序

SMTP协议工作原理

SMTP是工作在两种情况下：一是电子邮件从客户机传输到服务器；二是从某一个服务器传输到另一个服务器。SMTP也是个请求/响应协议，命令和响应都是基于ASCII文本，并以CR和LF符结束。响应包括一个表示返回状态的三位数字代码。SMTP在TCP协议25号端口监听连续请求。
连接和发送过程如下：

  • 建立TCP连接
  • 客户端发送HELO命令以标识发件人自己的身份，然后客户端发送MAIL命令；服务器正希望以OK作为响应，表明准备接收
  • 客户端发送RCPT命令，以标识该电子邮件的计划接收人，可以有多个RCPT行；服务器端则表示是否愿意为收件人接收邮件
  • 协商结束，发送邮件，用命令DATA发送
  • 以“.”号表示结束输入内容一起发送出去，结束此次发送，用QUIT命令退出

SMTP Inspection介绍

  • Allow only seven minimum SMTP
    commands:helo,mail,rcpt,data,rset,noop,and,quit(RFC 821)

  • Adds support for eight ESMTP
    commands:auth,data,ehlo,etrn,saml,send,soml,and vrfy

  • 默认在TCP/25上激活了ESMTP监控

  • 如果禁用此功能，所有SMTP命令都能穿越防火墙，邮件服务器潜在的漏洞就暴露在攻击者面前

POP简介

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

POP命令

1
2
3
4
5
USER			//键入用户名
PASS			//键入密码
STAT			//查看服务器状态
List			//罗列邮件
RETR 1			//收ID为1的邮件

SSL：安全套接层

SSL简介

  • SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。
  • SSL是一个不依赖于平台和运用程序的协议，用于保障TCP-based运用安全，SSL在TCP层和运用层之间，就想运用层连接到TCP来连接的一个插口

SSL加密知名协议

  • HTTP over SSL：加密网页流量是设计SSL的初衷,HTTP也是第一个使用SSL保障安全的运用层协议
    当Netscape在它的Navigator里面运用HTTP over SSL的时候，它使用https://来标识HTTP over SSL，因此HTTP over SSL就以HTTPS的格式被熟知。后来HTTPS在RFC2818被标准化。HTTPS工作在TCP 443号端口，但是普通的HTTP默认工作在TCP 80端口

  • Email over SSL：类似于HTTP over SSL，邮件协议例如：SMTP,POP3和IMAP也能支持SSL

SSL的位置

SSL介于应用层和TCP层之间。应用层数据不再直接传递给传输层，而是传递给SSL层，SSL层对从应用层收到的数据进行加密，并增加自己的SSL头。

工作流程

  • 服务器认证阶段：1）客户端向服务器发送一个开始信息“Hello”以便开始一个新的会话连接；2）服务器根据客户的信息确定是否需要生成新的主密钥，如需要则服务器在响应客户的“Hello”信息时将包含生成主密钥所需的信息；3）客户根据收到的服务器响应信息，产生一个主密钥，并用服务器的公开密钥加密后传给服务器；4）服务器回复该主密钥，并返回给客户一个用主密钥认证的信息，以此让客户认证服务器。

  • 用户认证阶段：在此之前，服务器已经通过了客户认证，这一阶段主要完成对客户的认证。经认证的服务器发送一个提问给客户，客户则返回（数字）签名后的提问和其公开密钥，从而向服务器提供认证。

SSL协议提供的安全通道有以下三个特性：

  • 机密性：SSL协议使用密钥加密通信数据。
  • 可靠性：服务器和客户都会被认证，客户的认证是可选的。
  • 完整性：SSL协议会对传送的数据进行完整性检查。