DSLBQ'S_BLOG

作者： dslbq

  • Wireshark抓包实例分析TCP重传（二）

    Wireshark抓包实例分析TCP重传（二）

    介绍

    TCP发送一个或一组报文，会等待收到报文的确认信息。重传，即发生在报文没有到达或确认信息没有及时返回的情况下。当发现网速变慢时，原因之一可能就是重传。发生重传的原因有多种，在客户机或服务器两边端口应用Wireshark有助于诊断问题。本文通过抓包实例阐述各种可能性。

    更多信息

    诊断过程:

    1. 在相应端口开始抓数据。
    2. 找到Analyze | Expert Info菜单。
    3. 在Notes之下，查找Retransmission。
    4. 点击（+）符号即可打开重传列表。鼠标点击各行可在抓包面板看到重传报文。
    5. 现在问题来了，怎样定位问题呢？
    6. 通过以下方式查看重传来自哪里：
      • 在Expert Info窗口一个一个查看报文，在抓包面板查看哪些是重传报文（适合于有经验的用户）
      • 在报文面板，配置显示过滤器expert.message == “Retransmission (suspected)”，即可看到抓包文件中所有重传报文
      • 应用过滤器，在Statistics & Conversations窗口查看Limit to display filter部分。

    Case 1：重传至多个目的地址

    以下截屏中，可看到有多次重传，分布于多台服务器，目的端口号为80（HTTP）。也可以发现重传由端口10.0.0.5发送，因此报文是丢失在发往Internet的途中，或确认信息没有及时从web服务器发回。

    问题发生在发往Internet的线路上，怎样知道是什么问题呢？

    1. 从Statistics菜单，打开IO Graph。
    2. 本例中，可看到链路负载非常低。可能是有故障，或有另一条高负载链路。
    3. 可以通过登录到通信设备或SNMP浏览器查看引起重传的原因：报文丢失及错误。参考以下截屏

    Case 2：重传至单一连接

    如果所有重传发生于同一IP，同一TCP端口号，则可能是慢速应用引起。看以下截屏：

    对于单一连接的重传，进行以下操作：

    1. 从Statistics菜单打开Conversations，选择Limit to display filter，可以看到所有发生重传的会话，本情况下，是一个单一会话。
    2. 如下图所示，通过选择IPv4标签可看到从哪个IP地址重传：

    3. 如下图所示，通过选择TCP标签看到重传来自哪一端口：

    要定位问题，进行以下步骤：

    1. 查看IO graph，确保链路不忙。（链路忙的表征例如流量接近带宽。例如，带宽为10Mbps，在IO graph中看见流量接近10Mbps，这就表明链路负载较高。不忙的链路IO会有很多高低起落，峰值以及空闲间隙）。
    2. 如果链路不忙，则可能是服务器对于IP地址10.1.1.200有问题（10.90.30.12发送了绝大多数重传，所以可能是10.1.1.200响应较慢）
    3. 从报文面板可以看出应用是FTP数据。有可能FTP服务器工作于active模式。因此在端口2350打开连接，服务器将端口更改为1972，所以可能是慢速FTP软件响应问题引起的重传。

    Case 3：重传模式

    观察TCP重传的一个重要考量是是否能看出一些重传模式。在以下截屏中，可以看见所有重传来自单一连接，位于客户端与服务器的NetBIOS会话服务（TCP端口139）。

    看起来像一个简单的服务器/客户端问题，但查看抓包面板，如下图所示：

    可以看见重传总是周期性的每30ms发生一次。问题是由于客户端在软件中执行了财务进程，导致软件每30-36ms就减速一次。

    Case 4：应用无响应导致重传

    另一个可能导致重传的原因是客户端或服务器没有响应请求。这种情况下，会看到五次重传，时间也会逐渐延长。五次连续重传后，发送方认为连接断开（某些情况下，会发送reset来关闭连接，取决于软件实施）。断开连接之后，可能会发生两件事情：

    • 发送SYN请求至客户端，以打开一个新的连接。这种情况下用户会看到应用冻结，过了15-20秒之后重新开始工作。
    • 不发送SYN，用户需要重新运行应用程序（或应用程序的一部分）

    下图显示了打开新连接的情况：

    Case 5：由于延时变化导致重传

    TCP能够充分容忍延时，前提是延时大小不发生变化。当延时改变时，就会发生重传。诊断是否由该原因引起的方法：

    1. 第一件事是ping目的地址，并且得到检查通信链路延时的第一条信息。
    2. 检查延时变量，可能由以下原因引起：
      • 由于不稳定或繁忙通信链路引起。这种情况下，可以看到ping命令的延时变化，通常由于带宽较窄。
      • 由于应用过载或资源不足，这种情况下，只有该应用发生很多重传。
      • 通信设备过载（CPU,缓存）引起延时。检查方式直接连接通信设备。
    3. 使用Wireshark工具诊断延时问题。

    如果重传达到0.5个百分比，性能就会下降，断开连接将会达到5个百分比。这取决于应用及其对于重传的敏感性。

    定位重传问题

    当你看到通信链路上发生重传，进行以下步骤：

    1. 定位问题——是一个特定IP地址，特定连接，特定应用，还是其他问题。
    2. 查看问题是否由于通信链路，丢包，慢速服务器还是PC。查看应用是否慢速。
    3. 如果不是由于上述原因，检查延时变化。

    工作原理:

    TCP序列号/确认机制详见：TCP确认机制 。那么重传是由什么原因引起呢？当报文确认信息丢失，或ACK没有及时到达，发送方会进行以下两步操作：

    1. 再次发送报文
    2. 减少吞吐量。

    以下图中展示了重传减少发送方吞吐量（红色细线）：

  • Wireshark抓包实例诊断TCP连接问题(一)

    Wireshark抓包实例诊断TCP连接问题(一)

    介绍

    TCP进程通讯时，双方打开连接，发送数据，最后关闭连接。当TCP打开连接时，从源端口到目的端口发送一个请求。在应用建立或关闭时可能发生一些问题。本文讨论用Wireshark网络抓包的方法来定位及解决这一问题。

    更多信息

    问题的表现形式:

    问题可能有多种表现类型：

    • 尝试运行应用程序但发现应用程序无法工作。尝试浏览网络但无法获得响应。
    • 尝试发送邮件但无法连接到邮件服务器。
    • 问题可能由简单原因引起，如服务器宕机，服务器上没有运行应用程序，或在客户端到服务器的某一处网络断开。
    • 问题也可能由复杂原因引起，如DNS问题，服务器内存不足无法连接（例如某一应用占用高内存空间），重复IP，以及其他原因。

    处理方法:

    下文会介绍解决问题的线索以及如何通过抓包来诊断TCP连接问题。通常，这些问题会导致运行应用程序时无法得到任何结果。

    当你在运行一个应用程序时，例如数据库客户端，邮件客户端，观看视频等等，而又无法获得输出，按照以下步骤诊断：

    1. 确认服务器和应用程序正在运行。
    2. 确认客户端正在运行，IP地址已配置（手动或通过DHCP），并连接至网络。
    3. Ping服务器并确认连接正常。
    4. 在某些情况下，ping不通服务器但连接正常。这是由于防火墙拦截了ICMP信息，所以如果无法ping通并不一定表示连接有问题。防火墙可能是网络中的专用设备或Windows/Linux/UNIX终端设备上安装的防火墙。
    5. 抓包文件中，查找以下模式
    • 三重SYN信息而没有响应（见以下截屏）
    • SYN信息带一个reset(RST)响应

    这两种情况下都有可能是防火墙拦截了特定应用程序或应用程序没有在运行。

    以下截屏是一个简单的case：客户端无法连接到web服务器81.218.31.171（报文61,62和63）。可能是由于不被防火墙允许，或服务器发生故障。可以看到另一个站点108.160.163.43（报文65,66和67）的连接正常，因此连接问题仅限于81.218.31.171。

    下例是一个这种情况相对复杂的case。该case中，客户想要登录到camera服务器来访问远程站点的camera。camera服务器的IP地址为135.82.12.1，问题在于客户能够看到服务器主页上的登录窗口，但无法登进系统。在下面的截图中可以看到，打开了一个到IP地址135.82.12.1的连接。到HTTP服务器的TCP连接是打开的，一开始看上去没有连接问题：

    当我们过滤出目的IP地址为135.82.12.1的数据流，也就是camera服务器。这里可以看到，当尝试连接TCP端口6036时，得到了一个RST/ACK响应，有以下可能性：

    • 防火墙拦截了端口6036
    • 如果配置了端口地址转换（PAT），那么仅转换端口80而非6036
    • 用户名和密码验证是在TCP端口6036上完成的，防火墙仅允许端口80，验证被拦截，应用无法工作

    总之，当无法正常连接服务器时，检查服务器和客户端是否所有TCP/UDP端口都能通过网络转发，以及是否有未知的端口。

    工作过程：

    TCP连接开始时，发生了以下三步：

    1. 客户端TCP进程发送了一个SYN报文。该报文中SYN标志位设置为1。这一报文中客户端：
      • 指定自己的初始序列号。这是客户端发送给服务器的第一个字节。
      • 指明自己的窗口大小。这是客户端分配给进程的缓存大小（位于客户端的RAM）。
      • 设置自己将要使用的选项：MSS，Selective ACK，等等。
    2. 当服务器收到建立连接请求，服务器：
      • 发送SYN/ACK给客户端，确认接收到SYN请求。
      • 指明服务器端的初始序列号。这是服务器发送给客户端的第一个字节。
      • 指明服务器的窗口大小。这是服务器分配给进程的缓存大小（位于服务器RAM）。
      • 回复请求选项并设置服务器端选项。
    3. 当接收到服务器的SYN/ACK，客户端：
      • 发送ACK报文给服务器，确认从服务器接收到SYN/ACK.
      • 指明客户端窗口大小。尽管这一参数在第一个报文中定义过了，服务器还是会参考这个值，因为这是最新的窗口大小。

    在TCP头部的选项字段中，有以下几个主要选项：

    • Maximum Segment Size（MSS）：TCP数据报的最大字节数，即从TCP头部开始直到报文末尾的字节数。
    • Windows Scale Option (WSopt)：这一因子与TCP头部的Window Size字段相乘，通知接收方扩大缓存。由于头部最大窗口大小是64KB，乘以因子4也就是256KB窗口大小。
    • SACK：Selective ACK，该选项使连接双方能够仅确认指定报文，当单个报文丢失，只有这个报文会被重传。连接建立时，双方都需要同意SACK。
    • Timestamps Option（TSopt）：该参数指客户端和服务器之间的延时。

    在这一阶段，双方：

    • 同意建立连接
    • 知道对方的初始序列号
    • 知道对方的窗口大小

    在建立连接时，除了三路握手信号之外，其他都表示有问题。包括SYN没有响应，SYN之后SYN/ACK最后没有ACK，SYN响应为RST，等等。

    总结：

    • 如果SYN报文收到回复RST，则检查拦截了port号的防火墙。
    • 三次SYN而没有任何回复，或者是由于应用程序没有响应，或者是由于防火墙拦截了特定端口上的请求。
    • 永远记住确认一下是否有NAT，端口转发，以及涉及TCP和UDP端口的机制。这些机制可能会中断TCP正常操作。
  • DHCP

    DHCP

    介绍

    动态主机设置协议（Dynamic Host Configuration Protocol, DHCP）是一个局域网的网络协议，使用UDP协议工作，主要有两个用途：

    • 给内部网络或网络服务供应商自动分配IP地址给用户
    • 给内部网络管理员作为对所有电脑作中央管理的手段

    本文介绍DHCP的工作原理。

    更多信息

    DHCP工作原理:

    DHCP从一个IP地址池中提供IP地址，该池有DHCP服务器数据库定义，称为scope。如果客户端接受这一地址，则它可在一个预定义的期限内使用该地址，称为租约。如果客户端无法从DHCP服务器获取IP地址，它就无法正常初始化TCP/IP。

    在DHCP为客户端配置TCP/IP参数时，DHCP服务器和客户端都需要经历四步过程。注意到很多通讯是通过广播的方式来完成的。如果路由器无法转发这些DHCP消息时，广播通信可能会造成问题。

    当客户端处于以下四种状态之一时，必须使用IP租约进程：

    • 配置使用DHCP的客户端第一次初始化TCP/IP；
    • 客户端请求特定的IP地址但服务器拒绝了该地址，在DHCP丢弃租约时即会发生。
    • 客户端之前租约了一个IP地址，但之后释放了该IP地址，现申请一个新的租约。这种情况发生于用户输入ipconfig /release和ipconfig /renew命令时。

    客户机请求IP地址（DHCP DISCOVER）:

    当一个IPv4客户机启动时监测到需要IP地址，它会初始化一个TCP/IP的限制版本，之后广播一个报文请求寻找DHCP服务器的地址。该广播报文告知监听服务器客户端需要IP地址信息。DHCP客户端发送的报文这一阶段包括租约请求，客户端源地址，0.0.0.0，目的地址，即广播地址255.255.255.255。报文也包括客户端硬件MAC地址和机器名，该信息也指明了向DHCP服务器发起请求的设备。

    客户端向DHCP服务器发送请求IP地址的真实报文称为DHCP DISCOVER报文。网络上每一台安装了TCP/IP协议的主机都会接收到这种广播信息，但只有DHCP服务器才会做出响应。

    服务器提供IP地址（DHCP OFFER）:

    所有拥有有效IP地址的DHCP服务器都会向DHCP客户端提供IP地址信息。它响应以地址池中一个未分配的IP地址供请求主机使用。要能够响应DHCP DISCOVER报文，DHCP服务器必须拥有客户端的有效IP配置信息。DHCP服务器回复的DHCP OFFER报文包含以下信息：

    • 客户端的硬件地址
    • 提供的IP地址
    • 合适的子网掩码
    • 租约有效期
    • 服务器ID，即DHCP服务器的IP地址

    客户机选择IP地址（DHCP REQUEST）：

    DHCP客户端选择它所接收到的第一个DHCP OFFER报文提供的IP地址。之后，它把这一信息广播至网络。该报文中，客户端请求服务器提供给它的IP地址。这是因为客户端可能收到不止一个DHCP服务器发送的offer。通过广播这一请求，客户端告知其他DHCP服务器不会再接受其他offer。为了进一步确保客户端接受的服务器offer没有疑义，DHCP REQUEST报文中还包含以下信息：

    • 提供所接受offer的服务器IP地址
    • 客户端硬件地址
    • 客户端接受的IP地址

    服务器确认IP租约（DHCP ACK）：

    DHCP服务器对客户端作出响应，将IP地址分配给客户端。之后，它发送DHCP ACK确认信息给客户端。该信息包含IP地址的有效租约以及其他配置信息。

    有时，在客户端接收服务器提供的租约后，DHCP租约请求仍可能不成功。可能有以下几种情况：

    • 由于客户端移动至其他子网，IP地址无效
    • 客户端尝试租约它之前的IP地址但该IP地址不再可用

    在上述情况下，服务器会发送一条不成功信息DHCP NACK。收到DHCP NACK的客户端必须重新开始整个DHCP初始化进程。也就是说，它必须发送另一个DHCP DISCOVER报文查找新的IP地址。

  • DNS

    DNS

    介绍

    因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。

    更多信息

    DNS基础：

    DNS命名空间是一个分层结构，类似于Unix文件系统。如下图的分层空间所示。

    每个节点都有一个标签，最多可以有63个字符。树结构的根部是一个特殊的标签为null的节点。树结构中节点的域名就是一串标签列表，从该节点开始，一直到根节点，通过dot来将标签分开。（这是与Unix文件系统不同的地方，将路径名放在最前沿着树结构下来）。树结构中的每一个节点必须有一个唯一的域名，但是树结构中不同的point可以有相同的标签。

    域名分为绝对域名与相对域名。绝对域名也称为完全合格的域名FQDN(Full Qualified Domain Name)，它是以“.”结尾的域名，例如sun.tuc.noao.edu.。如果不以“.”结尾，则假设该域名需要被补充完整。域名如何补充则取决于使用的DNS软件。

    顶级域名分为三个区域：

    1. arpa是用来做反向域名解析的特殊域。
    2. 七个3字母域名称为普通域名，也有称为组织域。
    3. 所有两个字母域名是基于ISO 3166国家代码，称为国家域名或地理域名。

    上图中没有显示的很重要的一点是DNS中责任的分派。没有一个单一的实体来管理树中的每一个标签。相反，一个实体（网卡）维持树中的一部分（顶级域名）并将其他责任分配给zone中其他实体。

    zone指DNS树中分开管理的子树。例如，二级域名就是一个常见的zone，noao.edu。很多二级域名又分为更小的zone。例如，一所大学按照系别，公司按照部门分为分为更小的zone。

    熟悉Unix文件系统的会注意到DNS树按zone分区很像逻辑Unix文件系统分为物理磁盘分区。如同我们从上图中无法看出zone的委托授权管理位于何处，从Unix文件系统的类似图中也难以看出哪个目录在哪个磁盘分区上。

    一旦zone的委托授权分派好，zone的负责人需要为其提供多个域名服务器。当zone中安装了新的机器，zone的DNS管理员为其分配域名与IP地址，并将信息输入域名服务器的数据库中。域名服务器委托授权管理一个或多个zone。zone管理人员必须为其提供一台主域名服务器以及一个或多个二级域名服务器。主服务器和二级服务器必须相互独立并冗余，以使zone不会受到单点故障的影响。主服务器和二级服务器的区别在于，主服务器从磁盘文件加载zone的所有信息，而二级服务器从主服务器获取所有信息。这一过程称为zone transfer。

    当新的机器添加到zone中，管理员将合适的信息（至少需要名称和IP地址）添加到主服务器系统的磁盘文件中。之后告知主域名服务器重新读取自己的配置文件。二级服务器定期查询（通常3小时一次），如果主服务器有新的数据，二级服务器通过zone transfer来获取。

    当域名服务器没有所需信息时怎么办呢？它必须联系另外一台域名服务器。这是DNS的分布式特性。并不是每一台服务器都知道如何联系其他域名服务器，但每一台服务器都知道如何联系根域名服务器。根服务器的IP地址存放于主服务器的配置文件中。主服务器必须知道根服务器的IP地址，而非DNS名。之后，主服务器获知所有二级域名服务器的名称和位置（即IP地址）。整个交互过程是：发起请求的域名服务器必须联系根服务器，根服务器告知请求服务器联系另外一台服务器，这样逐级进行。

    DNS的一个基本属性是缓存。即，当一个域名服务器收到一条映射信息（如一个主机名的IP地址），它会将该信息放入缓存，以使之后的查询可以使用缓存后的结果，而无需额外发起对其他服务器的查询。

  • HTTP

    HTTP

    介绍

    HTTP是一个由请求与响应组成的客户端与服务端交互协议。浏览器发送一个HTTP请求到指定的URL地址，持有此URL地址的WEB服务器将返回一个HTTP请求。请求的类型有GET,POST, HEAD, PUT, DELETE, OPTIONS和TRACE等。

    更多信息

    HTTP操作模式与客户端/服务器通信:

    HTTP只关心一个功能：从web服务器到web客户端的超文本文件以及其他文件的传输。从通信的角度来看，客户端主要负责发送请求给服务器，服务器对请求作出响应。相比FTP和SMTP这样需要多个通信步骤和命令/响应序列的应用层协议，HTTP更像BOOTP和ARP。

    基本的HTTP客户端/服务器通信：

    最简单的HTTP操作包括一个使用web浏览器的HTTP客户端，和一个HTTP服务器，通常称为web服务器。在TCP连接创建之后，以下两步通信过程如下：

    客户端请求：HTTP客户端根据HTTP协议标准发送HTTP请求信息，该信息指定客户端想要获
    取的资源或包括准备提供给服务器的信息。
    服务器响应：服务器读取并解释该请求。对请求作出相应行为并创建HTTP响应信息，发回给
    客户端。响应信息包括该请求是否成功，也包括客户端请求的资源内容。

    HTTP消息格式：

    使用HTTP的设备通信都是通过HTTP消息来完成，其中只有两种类型：请求和响应。客户端
    通常发送请求和接收响应，服务器接收请求和发送响应。信息使用的是文本的形式。

    常规HTTP消息格式如下所示：

    <起始行> 
<首部字段> 
<空白行>
[<主体>]
[<尾部>]
    • 起始行：包含消息的类型。请求消息中，这一行以方式的形式表明消息为请求类型，并制定一个URI(Uniform Resource Identifier)指明请求的对象资源。响应通过起始行来表明请求响应的状态信息。
    • 首部字段：HTTP定义了多种类型的首部字段。通过功能分组，除了主机头以外，几乎所有首部字段都是可选的。格式如下：<header-name><header-value>。
    • 主体：可选的，包含客户端和服务器通信所需的一系列信息，如响应的详细错误消息。更加常见的是承载文件或其他资源，HTTP标准中称为实体。由于大多数客户端请求服务器发送文件或其他资源，实体在响应信息中最为常见。
    • 尾部：HTTP/1.1默认使用永久链接，消息在服务器与客户端之间以流的形式传输，需要标记消息的结束点和开始点。

    HTTP请求消息：

    客户端通过打开一个TCP连接发起与服务器的HTTP会话，之后发送HTTP请求信息

    起始行

    主要有三个用途：

    • 表明客户端想要进行的命令或行为
    • 指定行为想要获取的资源
    • 告知服务器客户端使用的HTTP版本

    起始行的语法为：

    <METHOD> <request-uri> <HTTP-VERSION>

    Method

    method就是客户端想要服务器做什么，三种比较常用：GET，HEAD和POST。

    GET从服务器向客户端发送发送命名资源
    PUT将来自客户端的数据存储到一个命名的服务器资源中去
    DELETE从服务器中删除命名资源
    POST将客户端数据发送到一个服务器网关应用程序
    HEAD仅发送命名资源响应中的HTTP首部

    Request URI

    Request URI是请求所申请资源的URI。目前URI通常值符合Web URL语法的HTTP URL。有趣的是，HTTP起始行所使用的URL形式通常与HTML文件或用户输入的不同。这是因为一个完整URL中的部分信息是用来控制HTTP本身的。这是用户和HTTP客户端通信所需，而不包括在客户端对服务器的请求中。在请求中指定资源的标准方式是在起始行中加入路径和文件名（以及可选的查询信息），同时在主机头字段指定主机。

    例如：假设用户输入URL：http://www.myfavoritewebsite.com:8080/chatware/chatroom.php，我们不需要发送http:到服务器。客户端将余下的信息拆分成URI /chatware/chatroom.php主机行会包括www.myfavoritewebsite.com:8080。因此，请求的开始内容如下：

    GET    /chatware/chatroom.php    HTTP/1.1
Host:    www.myfavoritewebsite.com:8080

    这一准则的例外是当请求对象是代理服务器时。这时请求就要使用完整URL的形式，以使代理可以作为初始客户端来处理该请求。请求如下所示：

    GET    http://www.myfavoritewebsite.com:8080/chatware/chatroom.php    HTTP/1.1

    请求首部

    在请求首部，提供给服务器关于请求的详细信息。所有请求首部都使用相同的结构，但按照以下功能分类：

    普通报头普通报头通常指消息本身，通常用于控制其处理过程或提供给接收方额外信息。这类报头不限于请求或响应信息，所以两者都可能出现。同样，也与所承载的实体没有特别关系。

    请求报头 这类报头告知服务器关于客户端请求的更多信息，给予客户端更多关于请求处理的控制。例如，一些请求报头用于指定条件请求，只有在特定条件时才执行。其他告诉服务器响应信息中客户端能够徐立的格式或编码。如：

    • Accept:告诉服务器端，接受哪些类型的信息。
    • Accept-Encoding:可接受的内容编码。
    • Accept-Lanague:指定一种自然语言。
    • Connection:表示是否需要持久连接。如果Servlet看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时显著地减少下载所需要的时间。
    • Cookie:最重要的请求头信息之一， 每次请求时都会携带上Cookie以方便服务器端识别是否是同一个客户端。
    • Host:host请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来。
    • User-Agent:用户代理，一般情况是浏览器。我们上网登陆论坛的时候，往往会看到一些欢迎信息，其中列出了客户端操作系统的名称和版本，所使用的浏览器的名称和版本，实际上，服务器应用程序就是从User-Agent这个请求报头域中获取到这些信息。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务器。

    HTTP回复信息

    每一个HTTP客户端发送给服务器请求都会要求服务器发回响应信息。在特定情况下，服务器会发回两条响应，一条初步响应和一条实际上的响应。一般，一个请求产生一个响应，表明服务器对于该请求的处理结果，并且响应往往消息主体还携带一个实体（文件或资源）。

    响应消息格式如下：

    <状态行>
<响应首部>
<响应实体>

    如下图所示:

    状态行

    状态行是响应信息的起始行，作用有两个：告知客户端服务器使用的协议版本以及沟通客户端请求的处理结果。状态行语法格式如下：

    <HTTP-VERSION><status-code><reason-phrase>

    HTTP版本

    状态行中的HTTP-VERSION标签与请求信息中的目的一样。服务器要求返回的版本号不得高于客户端发送的版本号。

    响应码和文本描述

    状态码和文本描述提供客户端请求处理结果的信息。服务器通过3位数字状态码告知客户端处理结果。目的是为了方便客户端HTTP软件采取合适的行动。文本描述将服务器响应显示给客户端用户。

    状态代码由 3 位数字组成， 表示请求是否被理解或被满足，状态描述给出了关于状态码的简短的文字描述。状态码的第一个数字定义了响应类别，后面两位数字没有具体分类。第一个数字有5 种取值，如下所示:

    • 1xx：指示信息——表示请求已经接受，继续处理
    • 2xx：成功——表示请求已经被成功接收、理解、接受。
    • 3xx：重定向——要完成请求必须进行更进一步的操作
    • 4xx：客户端错误——请求有语法错误或请求无法实现
    • 5xx：服务器端错误——服务器未能实现合法的请求。

    常见状态代码、状态描述、说明：

    200    OK               //客户端请求成功
400    Bad Request      //客户端请求有语法错误，不能被服务器所理解
401    Unauthorized     //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403    Forbidden        //服务器收到请求，但是拒绝提供服务
404    Not Found        //请求资源不存在，eg：输入了错误的URL
500    Internal Server Error    //服务器发生不可预期的错误
503    Server Unavailable       //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

    响应首部

    响应首部可能包括：

    Location（重定向）：Location响应报头域用于重定向接受者到一个新的位置。例如：客户端所请求的页面已不存在原先的位置，为了让客户端重定向到这个页面新的位置，服务器端可以发回Location响应报头后使用重定向语句，让客户端去访问新的域名所对应的服务器上的资源。当我们在JSP中使用重定向语句的时候，服务器端向客户端发回的响应报头中，就会有Location响应报头域。

    Server响应头：Server响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释，产品标识一般按照重要性排序。它和User-Agent请求报头域是相对应的，前者发送服务器端软件的信息，后者发送客户端软件(浏览器)和操作系统的信息。下面是Server响应报头域的一个例子：Server: Apache-Coyote/1.1

    实体头：请求消息和响应消息都可以包含实体信息，实体信息一般由实体头域和实体组
    成。实体头域包含关于实体的原信息，实体头包括Allow、Content- Base、Content-
    Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、
    Content-Range、Content-Type、 Etag、Expires、Last-Modified、extension-header。
    extension-header允许客户端定义新的实体头，但是这些域可能无法未接受方识别。实体可以
    是一个经过编码的字节流，它的编码方式由Content-Encoding或Content-Type定义，它的长
    度由Content-Length或Content-Range定义。

    • Content-Type：实体头用于向接收方指示实体的介质类型，指定HEAD方法送到接收方的实体介质类型，或GET方法发送的请求介质类型，如：”application/octet-stream”。
    • Last-modified：实体头指定服务器上保存内容的最后修订时间。
    • Accept-Ranges：这个字段说明Web服务器是否支持Range（是否支持断点续传功能），如果支持，则返回Accept-Ranges： bytes，如果不支持，则返回Accept-Ranges： none。
    • Content-Encoding：文档的编码（Encode）方法。它的值指示了已经被应用到实体正文的附加内容编码，因而要获得Content- Type报头域中所引用的媒体类型，必须采用相应的解码机制。Content-Encoding主要用语记录文档的压缩方法，下面是它的一个例子： Content-Encoding: gzip。如果一个实体正文采用了编码方式存储，在使用之前就必须进行解码。
    • Expires： 给出响应过期的日期和时间。通常，代理服务器或浏览器会缓存一些页面。当用户再次访问这些页面时，直接从缓存中加载并显示给用户，这样缩短了响应的时间，减少服务器的负载。为了让代理服务器或浏览器在一段时间后更新页面，我们可以使用Expires实体报头域指定页面过期的时间。当用户又一次访问页面时，如果Expires报头域给出的日期和时间比Date普通报头域给出的日期和时间要早(或相同)，那么代理服务器或浏览器就不会再使用缓存的页面而是从服务器上请求更新的页面。不过要注意，即使页面过期了，也并不意味着服务器上的原始资源在此时间之前或之后发生了改变。
    • Refresh：表示浏览器应该在多少时间之后刷新文档，以秒计。除了刷新当前文档之外，你还可以通过setHeader(“Refresh”, “5; URL=http://host/path”)让浏览器读取指定的页面。 注意这种功能通常是通过设置HTML页面HEAD区的＜META HTTP-EQUIV=”Refresh” CONTENT=”5;URL=http://host/path”＞实现。
    • Allow：服务器支持哪些请求方法（如GET、POST等）。
    • Content-Disposition：打开一个网页时，浏览器会首先看是否有Content-Disposition:attachment这一项，当是“Content-Disposition: attachment”时是下载，“Content-Disposition:inline”是在线打开文件

    下面是一个响应消息

    HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Accept-Ranges: bytes
ETag: "34aa387-d-1568eb00"
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

    HTTP方法：

    GET

    GET方法请求服务器检索由该HTTP请求中的URL指定的资源并在回复中发给客户端。这是最基本的请求类型，也是占大多数的HTTP数据流。当你输入一个常规URL或点击一个文档中的链接，通常就是提示Web浏览器发送GET请求。

    对于GET的处理取决于若干因素。如果URL正确并且服务器能够找到资源，会发送合适的响应给客户端。返回资源需取决于请求对象的特性。如果无法妥当处理请求，则会产生一个错误信息。在使用缓存的情况下，代理服务器甚至客户端自己就可以满足请求。对于某种特定报头如 If-Modified-Since 或 If-Match， GET请求的含义可能随之而改变，要求服务器仅在满足特定条件时发送资源。这类请求称为条件GET。类似的，客户端可以使用Range头来要求服务器仅发送部分资源。这类请求称为部分GET。

    HEAD

    HEAD方法同GET，但告知服务器不要发送消息实体。客户端通常使用这种方法来检查资源是否存在，状态，或文件大小，再决定是否需要服务器发送整个文件。HEAD请求的处理与GET相同，除了只返回头部而不返回实际的资源之外。

    POST

    POST方法允许客户端发送任意数据的实体到服务器以进行处理。它通常同于客户端提交例如交互式HTML信息给服务器程序，之后服务器作出行动并发回响应。这种方法用于各种在线进程。请求中的URL指定服务器上接受数据的程序名。

    PUT

    这种方法请求服务器将请求中的实体保存在请求中的URL里。PUT中，URI指明请求中的实体，因而PUT能够让文件复制到服务器，在GET请求中文件能够被复制到客户端。与之相反，POST中URI标识的程序处理请求中的实体，因此通常应用于交互式程序。PUT用法很多，如上传内容到网站，这种情况下必须加以认证。但是，在站点上存储文件通常使用其他方式，如FTP。

    TRACE

    客户端通过这种方法接收发至服务器的请求，用于诊断目的。

  • ICMP和ARP

    ICMP和ARP

    介绍

    ICMP是网络控制消息协议，主要用于传递查询报文与差错报文。ARP是地址解析协议，它的作用是在以太网环境下，通过3层的IP地址来找寻2层的MAC地址，得到一张ARP缓存表。转发数据的时候根据ARP缓存表来进行传输。

    更多信息

    IMCP:

    Internet操作是由路由器严密监控的。当路由器端处理报文时如有意外发生，事件通过ICMP报告给发送端。ICMP也用来测试Internet。ICMP信息封装在IP报文中，最重要的一部分如下表所列：

    • DESTINATION UNREACHABLE：用于当路由器无法找到目标地址或当设置了DF位的报文无法递送，因为路径上存在“小报文”网络。
    • TIME EXCEEDED：由于报文TTL（Time to live）计数器到达0时。该事件是报文在回环，或计数器值设置过低的迹象。对于这一错误信息的聪明的应用是traceroute工具，traceroute发现从主机到目的IP地址路径上的路由器。它向目的地发送IP包，第一次的时候，将TTL设置为1，引发第一个路由器的Time Exceeded错误。这样，第一个路由器回复ICMP包，从而让出发主机知道途径的第一个路由器的信息。随后TTL被设置为2、3、4，…，直到到达目的主机。这样，沿途的每个路由器都会向出发主机发送ICMP包来汇报错误。traceroute将ICMP包的信息打印在屏幕上，就是接力路径的信息了。这并不是TIME EXCEEDED信息的本意，但却是非常有用的故障排查工具。
    • PARAMETER PROBLEM：表示报文头字段发现了非法值。这一问题表明发送主机的IP软件或可能是途经的路由器发生了bug。
    • SOURCE QUENCH：以前用来节制发送太多报文的主机。当主机接收到该信息，它预计将放缓发送报文。现在很少使用，因为当拥塞发生时，这类报文会起到火上浇油的作用，而且也不清楚如何做出回应。Internet中的拥塞控制现在大部分在传输层完成，使用报文丢失作为拥塞信号。
    • REDIRECT：用于路由器发现报文被错误路由的时候。路由器用该信息告知发送主机更新合适的路径。
    • ECHO和ECHO REPLY：主机发送ECHO和ECHO REPLY信息查看目前的目的地址是否可到达或是否alive。接收到ECHO信息之后，目的地址预计会发回一条ECHO REPLY信息。这些信息用在ping工具中来查看主机是否up以及是否挂在网上。
    • TIMESTAMP REQUEST和TIME REPLY类似：除了信息的到达时间以及回复的离开时间是记录在回复中的。这一工具可用于衡量网络性能。
    • ROUTER ADVERTISEMENT和ROUTER SOLICITATION：用于主机发现附近的路由器。主机需要从至少一个路由器学习IP地址来发送报文。

    ARP

    尽管Internet上的每台设备都有一个或多个IP地址，仅用这些地址仍然不能发送报文。数据链路层网卡如以太网卡不理解Internet地址。对于以太网，每一个以太网卡都有一个48bit的以太网地址。网卡基于这48bit以太网地址收发帧，网卡与32bit IP地址没有关系。

    从而产生一个问题：IP地址是如何映射到数据链路层地址，如以太网地址的呢？解释这一问题，让我们以下图为例：一个小型校园安装了两个/24网络。其中一个（CS）是交换以太网，位于Computer Science部门。网络地址为192.32.65.0/24。另一个局域网（EE）也是一个交换以太网，位于Electrical Engineering部门网络地址为192.32.63.0/24。这两个局域网通过IP路由器互连。以太网上的各台设备以及路由器各接口都有唯一的以太网地址，标签从E1到E6，以及CS或EE网络上唯一的IP地址。

    我们首先看一下host 1的用户如何向CS上的host 2用户发送报文。首先假设发送方知道目标接收方的名字，如xx.cs.uni.edu。第一步是查找host 2的IP地址。这一查找是通过DNS来完成的，DNS之后返回host 2的IP地址（192.32.65.5）。

    host 1的上层软件将目标地址192.32.65.5植入报文中并交给IP软件发送。IP软件查看该地址发现目标地址在CS网络上（即本地网络）。但是，还需要查找目的以太网地址来发送帧。一种解决方式是通过系统配置文件来将IP地址映射到以太网地址。当然这种方式是可能的，但对于有上千台设备的大型企业来说要保证这些文件都是更新状态是一项耗时的工作。

    比较好的方式是host 1发送一个广播报文到以太网询问谁有IP地址192.32.65.5。广播报文到达每一个CS网上的设备，各台设备检查自己的IP地址。只有host 2会回复自己的以太网地址E2。通过这种方式host 1学习到IP地址192.32.65.5的以太网地址E2。这种提问和回复的协议就称为ARP(Address Resolution Protocol)。使用ARP的一个优势是它的简单性。系统管理员无需指定各台设备的IP地址以及子网掩码，ARP自动完成剩下的工作。

    此时，host 1上面的IP软件构造以太网地址E2的报文，将IP报文（目的地址192.32.65.5）放在载荷部分。host 2的以太网卡检测到该帧，识别目标地址是自己，把它捞出来，产生一个中断。以太网驱动从载荷中将IP报文提取出来并传递给IP软件，软件查看到此报文地址正确并予以处理。

    提高ARP效率有很多种优化方法。运行ARP的设备将其结果放入缓存之中，以备短期内需要再次连接同一台设备。下一次可在设备的缓存中找到映射结果，就无需第二次广播。很多情况下，host 2需要发送一个回复，迫使它运行ARP来确定发送方的以太网地址。在host 1的ARP报文中包含IP到Ethernet映射可避免这一ARP广播。当ARP广播到达host 2，连接对（192.32.65.7, E1）进入host 2的ARP缓存。实际上，以太网上的所有设备都可以将这一映射放入自己的ARP缓存中。

    为了让映射能够更改，例如，当配置一台主机使用心得IP地址（但保留旧的以太网地址），几秒钟过后ARP缓存中的表项会过期。为了保持缓存信息更新并且优化性能，比较好的方法是每一台设备在配置时都广播它的映射信息。广播通常以ARP查找自己的IP地址的方式来完成。应当不会收到响应，但该广播的副作用是使每一台设备的ARP缓存都得到更新。这称为免费ARP（gratuitous ARP）。如果收到回复（不期望地），则两台设备指定了同一IP地址。网络管理员需解决这一问题才能使两台设备共同使用网络。

    再看上图，假设host 1想要向网络EE上的host 4(192.32.63.8)发送报文。host 1会发现目标IP地址不在CS网络上，它会将所有这类远端网络数据流发送给路由器，也称为默认网关（default gateway）。习惯上，默认网关是网络上的最低地址（198.31.65.1）。要发送帧给路由器，host 1还是必须知道路由器接口在CS网络上的以太网地址。路由器通过发送198.31.65.1的ARP广播来学习到E3地址，然后发送帧。路由器在Internet路径上将报文从一个路由器发送到下一个使用相同的查找机制。

    路由器的以太网卡收到此帧后将报文发给IP软件。从网络掩码中得知该报文应当发送到EE。如果路由器不知道host 4的以太网地址，就会再次使用ARP。上图列出了在CS和EE子网上观察到的帧中出现的源和目的以太网及IP地址。发现到各子网中以太网地址改变而IP地址保持不变（因为IP地址指明跨越所有互连子网的终点）。

    从host 1发送报文到host 4，而host 1不知道host 4位于不同网络也是可能的。解决方法是让CS子网上的路由器回复查找host 4的ARP并将自己的以太网地址E3作为回复内容。由于host4无法看到ARP请求（路由器不会转发以太网广播）所以无法直接回复。路由器之后会接收发往192.32.63.8的帧并转发到EE子网。这一方式称为代理ARP（proxy ARP）。用在一台主机想要出现在一个子网上但实际上位于另一子网的特定情形。

  • NAT原理与配置

    NAT原理与配置

    介绍

    NAT技术让少数公有IP地址被使用私有地址的大量主机所共享。这一机制允许远多于IP地址空间所支持的主机共享网络。同时，由于NAT屏蔽了内部网络，也为局域网内的机器提供了安全保障。

    NAT的基本实施过程包括使用一个预留给本地IP网络的私有地址成立组织的内部网络，同时分配给组织一个或多个公网IP地址，并在本地网络与公网之间安装一个或多个具有NAT功能的路由器。NAT路由器实现的功能包括将数据报中私网地址转换成公网地址，反向亦然。当有报文通过时，网络地址转换其不仅检查报文信息，还将报文头中的IP地址和端口信息进行修改，以使处于NAT之后的机器共享少数公网IP地址。

    更多信息

    何时使用NAT?

    因为NAT能够减少在网络环境中所需的公共IP地址需求，因此当两家公司重复内部地址合并时，这一技术是很有帮助的。当组织改变其Internet服务供应商（ISP），但网络管理员不想改变内部地址方案时，NAT也是一个很好用的工具。

    以下是应用NAT的场景：

    • 用户需要访问Internet但主机没有全球唯一的IP地址
    • 用户更改ISP需要对网络重新编号
    • 用户需要合并地址重复的内网

    通常NAT应用于边界路由器。例如，下图中NAT应用于企业连接到Internet的路由器上：

    NAT的优势与不足：

    优势 不足
    节约合法注册地址转换导致交换路径延时
    解决地址重叠问题 导致端到端IP地址无法追溯
    提高访问Internet灵活性某些应用程序无法使用
    网络变动无需地址重新编号

    网络地址转换类型：

    静态NAT：此类NAT在本地和全局地址之间做一到一的永久映射。须注意静态NAT要求用户对每一台主机都有一个真实的Internet IP地址。

    动态NAT：允许用户将一个未登记的IP地址映射到一个登记的IP地址池中的一个。采用动态分配的方法将外部合法地址映射到内部网络，无需像静态NAT那样，通过对路由器进行静态配置来将内部地址映射到外部地址，但是必须有足够的真正的IP地址来进行收发包。

    端口NAT（PAT）：最为流行的NAT配置类型。通过多个源端口，将多个未登记的IP地址映射到一个合法IP地址（多到一）。使用PAT能够使上千个用户仅使用一个全局IP地址连接到Internet。

    NAT术语：

    NAT术语还是比较直观的。NAT地址转换之后成为全局地址。通常是Internet上使用的公网地址。如果不访问Internet的话就不需要用到。

    本地地址：NAT地址转换之前用到的地址。内部本地地址实际上是尝试访问Internet的发送主机的私有地址。外部本地地址通常是连接到用户ISP的路由器接口，也是报文开始传输的公有地址。

    转换之后，内部本地地址之后被称为内部全局地址，而外部全局地址成为目标主机的地址。
    如下表所示：

    名称含义
    内部本地转换前的源主机内部地址
    外部本地Internet上识别到源主机的地址。通常是连接到ISP的路由器接口——真实的Internet地址。
    内部全局转换后连接到Internet的源主机地址。也是真实的Internet地址
    外部全局外部目标主机地址，同样是真实的Internet地址

    NAT实现细节：

    下图中，主机10.1.1.1将报文发送到有NAT功能的边界路由器。路由器将源IP地址识别为内部本地IP地址，在报文中转换源IP地址，并在NAT表中记录此次转换。

    配有新转换源地址的报文发送到外部接口。外部主机将报文发送给目的主机并且NAT路由器通过NAT表将内部全局IP地址转换回内部本地IP地址。

    PAT方式中，所有内部主机都转换为一个IP地址。如下图所示，除了内部本地IP地址和内部全局IP地址以外，还多了一个端口号。端口号帮助路由器识别哪一台主机应当收到返回数据。路由器使用来自各主机的源端口好来区别他们各自发出的数据。注意当报文离开路由器时有一个目标端口号80，而HTTP服务器将报文发回时目的端口号为1026。从而允许NAT转换路由器区别NAT表中的主机然后将目的IP地址转换回内部本地地址。

    本例中，端口号在传输层用户识别本地主机。如果必须要使用真实全局IP地址来识别源主机，那就只能通过静态NAT，并且会用光所有地址。PAT允许我们在传输层识别主机，从而理论上一个真实IP地址可被65，000台主机共享。

    静态NAT配置：

    ip nat inside source static 10.1.1.1 170.46.2.2

interface Ethernet0
ip address 10.1.1.10 255.255.255.0
ip nat inside

interface Serial0
ip address 170.46.2.1 255.255.255.0
ip nat outside

    在第一个路由器输出中， ip nat inside source 命令指定需要转换的IP地址。本例中，此命令配置了内部本地IP地址10.1.1.1到外部全局IP地址170.46.2.2的静态配置。

    在各接口下都有一条ip nat命令。ip nat inside命令将该接口识别为内部接口，ip nat outside命令将该接口识别为外部接口。回头看 ip nat inside source 命令，该命令将内部接口作为转换的源或起点。也可以这样使用：ip nat outside source。该选项表明指定的外部接口会成为转换的源或起点。

    动态NAT配置：

    动态NAT表示将一个地址池当作真实IP地址提供给内部一组用户。由于不使用端口号，对于同时尝试访问外部网络的用户必须提供真实的IP地址。

    以下是动态NAT配置的示例输出：

    ip nat pool todd 170.168.2.3 170.168.2.254
netmask 255.255.255.0
ip nat inside source list 1 pool todd

interface Ethernet0
ip address 10.1.1.10 255.255.255.0
ip nat inside

interface Serial0
ip address 170.168.2.1 255.255.255.0
ip nat outside

access-list 1 permit 10.1.1.0 0.0.0.255

    ip nat inside source list 1 pool todd 命令告知路由器将匹配access-list 1的IP地址转换到名为todd的IP NAT池中的一个地址。这里ACL并不是出于安全因素通过允许或拒绝数据来过滤报文。本例中，它是用来选择或指定我们感兴趣的数据流。当数据流与接入列表相匹配，就被拉入NAT进程转换。

    命令 ip nat pool todd 170.168.2.3 192.168.2.254 netmask 255.255.255.0用来创建地址池，之后被分配给请求全局地址的主机。做Cisco NAT故障排查时，一定要检查池中确保有足够地址提供转换给内部主机。最后，确保池名匹配，注意区分大小写。

    端口NAT配置：

    以下是端口NAT配置的示例输出：

    ip nat pool globalnet 170.168.2.1 170.168.2.1 netmask 255.255.255.0
ip nat inside source list 1 pool globalnet overload

interface Ethernet0/0
ip address 10.1.1.10 255.255.255.0
ip nat inside

interface Serial0/0
ip address 170.168.2.1 255.255.255.0
ip nat outside

access-list 1 permit 10.1.1.0 0.0.0.255

    端口NAT与动态NAT配置的不同之处在于：

    地址池变为只有一个IP地址

    在ip nat inside source命令最后加入overload关键字。

    本例中一个关键元素是使用了池中的一个IP地址作为外部接口IP地址。如果有其他可用地址如170.168.2.2可作为额外地址，这样做在内部大量用户同时为活跃状态，需要不止一个重载IP地址时很有帮助。

  • IP地址与子网

    IP地址与子网

    介绍

    起初，IP地址只有两层结构：网络与主机。子网地址向其中添加了一层新的结构：不同于仅有主机，网络有分为子网与主机。每一个子网的功能近乎于完整的网络。子网的添加构成了三层网络结构：包含子网的网络，各自由若干主机构成。IP地址由此被分为三个部分：网络ID，子网ID与主机ID。IP地址长度仍固定为32位，其中，A类网络8位子网掩码，B类网络16位子网掩码，C类网络24位子网掩码。

    更多信息

    对于每一类网络，网络数以及每一网络中包含的主机数，决定了它们各自占用多少比特位。这一准则同样适用于如何划分子网与主机。子网数量为2的子网ID次方，每一子网内的主机数为2的主机ID次方。假设一个B类网络154.71.0.0，网络ID占16位（154.71），主机ID占16位。没有子网的情况下一共可容纳65，534台主机。按照实际需求将16位划分为子网与主机：1位子网16位主机，或2与14，3与13。。。如下图所示，划分为5位子网与11位主机，子网数越多，主机数越少。

    搭建IP子网时，如何划分子网与主机数是最重要的问题之一。子网所占位取决于整个网络中的物理子网数，每一子网中的主机数不能超过子网划分所允许的最大数量。

    IP子网掩码，表示法以及子网计算:

    在没有子网的网络环境下，路由器通过IP地址的前八位来决定是哪一类型的网络，从而它们知道哪些是网络ID哪些是主机ID。划分子网时，路由器也需要知道主机ID是如何划分成子网ID与主机ID的，但是划分方法可以是任意组合，也没有办法从IP地址看出来。因此，必须有额外的信息告知解析IP地址的设备，这一信息称为子网掩码，以32比特数的形式呈现。

    掩码位的1和0结合布尔函数与和或的功能对于地址中的比特位进行选择或清除。子网掩码中的32位对应于IP地址相同位置上的数字。掩码位为1时，则地址中该位作为网络ID或子网ID，而掩码位为0时，则地址中该位表示主机ID。

    子网掩码为1：将IP地址中的0或1与1进行与操作，即：当子网掩码位为1，IP地址保持不变。
    子网掩码为0：任何数和0做与操作都是0，即：当子网掩码位为0，IP地址清零。

    因此，将子网掩码应用于IP地址，网络ID和子网ID保持不变，移除主机ID。执行此功能的路由器由此获得子网地址，因为它知道网络类型，因此能够区分网络位与子网地址位。

    举例来说，假设将B类网络154.71.0.0划分5位为子网ID，11位为主机ID。因此，子网掩码有16个1代表网络部分（B类网络），接下来5个1作为子网部分，11个0用作主机ID。二进制数表示为11111111 11111111 11111000 00000000，十进制数表示为255.255.248.0。

    举例：

    假设有一台主机IP地址154.71.150.42，路由器需要找出该主机位于哪一子网，则它的掩码操作如下图所示：

    结果，154.71.150.42所属的子网为154.71.144.0。另一台路由器能够从中区分出网络ID与子网ID，因为地址的前两个比特位是10，是一个B类网络。所以网络ID占16位，子网ID一定是17至21。这里，子网是10010，或子网18。

    提一个问题：既然子网掩码只是将网络地址划分出网络部分与子网部分，那为什么还要使用另外的32位比特数255.255.248.0，而不直接将IP地址第21位指定为分界线呢？这是有历史原因的：因为需要考虑不连续的掩码情况。同时，它也能够让路由器进行快速的掩码操作来找出子网地址。

    除了将16位划分为5位子网ID与11位主机ID，标准也允许前2位用作子网ID，4位用作主机ID，之后3位用作子网ID，7位用作主机ID。因此子网掩码为11000011 10000000。当然，这会造成混淆，是不推荐的，实际中也没有人会这么做。

    鉴于非连续掩码实际不会应用，以及现今的计算机速度大幅提升，新的表达法为154.71.150.42/21。

    IP子网掩码设定:

    假设B类网络154.71.0.0，没有子网的话一共有65,534台主机。划分子网时，按照以下方法：

    • 1位用作子网ID，15位用作主机ID：那么子网数为2^1，第一个子网是0，第二个子网是1。每一个子网的主机数是2^15-2，或32，766。
    • 2位用作子网ID，14位用作主机ID：那么子网数为2^2，四个子网0，1，2，3。每一个子网的主机数是2^14-2，或16，382。

    子网与主机ID位的划分取决于子网数与子网中最大主机数。假设一个B类网络中有10个子网，需要4位表示子网（2^4=16，2^3=8），12位用作主机ID，每一子网最多4，094台主机。

    如果你有20个子网，每一子网3，000台主机，那么就会碰到问题。需要5位表示20个子网，而3，000台主机需要12位。这时需要重新组织物理网络，如果无法做到，就需要第二个B类网络。

    自定义子网掩码的方法是：从指定网络类型的默认子网掩码中，从最左边的0位开始，按照需要的子网数将0改为1。假设C类网络200.13.94.0，最后8位可供划分子网与主机，则有6种不同的划分方法。假如使用3位作为子网ID，5位作为主机ID，那么：

    默认C类网络子网掩码：11111111 11111111 11111111 00000000
    将最左边的3位0改为1：11111111 11111111 11111111 11100000
    即子网掩码为：255.255.255.224。

    通常情况下，所有子网大小必须相同。因此，最大一个子网的主机数决定了需要多少位比特用作主机ID。因此前例中，前19个子网每个子网最多100台主机，而第20个子网需要3000个主机，就会碰到问题。这种情况下，需要将最后一个过大的子网拆成若干个小的子网。

  • 链路聚合

    链路聚合

    介绍

    链路聚合是在两个设备间使用多个物理链路创建一个逻辑链路的功能。这种方式允许物理链路间共享负载。交换机网络中使用的一种链路聚合的方法是EtherChannel。EtherChannel可以通过思科的端口聚合协议（Port Aggregation Protocol, PAgP）或链路聚合协议（Link Aggregation Protocol, LACP）来配置或协商。

    更多信息

    EtherChannel：

    EtherChannel本来是由思科开发，将若干Fast Ethernet或Gigabit Ethernet捆绑成一个逻辑通道的交换机到交换机的LAN连接技术。配置了EtherChannel之后的虚拟接口称为一个port channel。物理接口捆绑在一起，成为一个port channel interface。思科最早称之为EtherChannel Fast EtherChannel(FEC)，也称为Gigabit EtherChannel(GEC)，非思科公司常将链路聚合简写为LAG。

    通过EtherChannel，一个逻辑链路的速度等于所有物理链路的总和。例如，如果你用4个100 Mbps的以太网链路创建1个EtherChannel，则EtherChannel的速度是400 Mbps。但是也会有一些问题，并不是在所有情况下增加的容量都确实等于物理链路的速度之和。例如，四个1 Gbps链路组成的EtherChannel，默认每一个会话的速度还是限制在1 Gbps。

    默认情况下EtherChannel按照报文的目的MAC地址，给它指定一个物理链接。这也意味着EtherChannel上一个工作站与另一个服务器通信，只会使用到一条物理链路。实际上，EtherChannel上所有目的地为该服务器的数据流都只会走这一条物理链路。也就是说，一个用户同一时刻只会得到1 Gbps。这种模式也可以更改为每一个报文在不同的物理链路上发送，当有多个不同的目的地址时，每一条路径都可以得到利用。

    EtherChannel创建的是一对一的关系，即一个EtherChannel连接两个设备。可在两台交换机之间，或在一个激活了EtherChannel的服务器和一台交换机之间创建一个EtherChannel连接。但是，同一个EtherChannel连接无法将数据流发送到两台交换机。

    EtherChannel负载均衡：

    如前所述，EtherChannel默认情况下并不真的为各链路速度之和，只是在特定的链路发送特定的报文，给人的感知速度为所有链路的速度总和。EtherChannel 帧分发使用 Cisco 专有的hash算法。 该算法是确定性算法； 如果使用相同的地址和会话信息，则总是散列到通道中的同一端口。 此方法可避免无序传送数据包。这一算法中很重要的一点是，并不保证物理链路之间完全地均衡。

    该算法将目的MAC地址值hash成0-7的范围。无论EtherChannel中有多少链路都是同样的值。每一条物理链路都指定这八个值中的一个或多个，取决于EtherChannel中共有几条链路。

    下图显示了按照这种算法报文是怎样分布的，注意到分布并不总是均衡的。

    有八条物理链路的EtherChannel，每条链路指定单一值。有六条链路的EtherChannel，两条链路指定两个值，剩下四条链路指定四个值。这意味着两条链路（理论上均衡分布）会收到比剩余四条链路多一倍的数据流。从这张图很明显的看出，要使流量在各链路间均衡的分布（理想情况下），应当设置1，2，4，或8条物理链路。无论决定链路的信息是什么，算法都会将链路值hash为0-7。

    用户可根据需求对算法进行更改。默认行为是使用目的MAC地址，但是，按照软硬件版本的不同，还可以有如下选项：

    • 源MAC地址
    • 目的MAC地址
    • 源和目的MAC地址
    • 源IP地址
    • 目的IP地址
    • 源和目的IP地址
    • 源端口
    • 目的端口
    • 源和目的端口

    更改默认设置的原因由应用情况而定。下图显示了一种相对普遍的布局：

    一组用户连接到交换机A，通过EtherChannel连接到交换机B。默认按照每一个报文的目的MAC地址做负载均衡。但是，比较常见的情况是一台服务器的流量显著高于其他服务器。

    让我们假设该网络中email服务器接收到多于1 Gbps流量，而其他服务器大约为50Mbps。使用基于目的MAC地址的方法会导致在EtherChannel丢包，因为目的地为email 服务器 MAC地址的报文会走同一条物理链路。一条链路发生过载时报文不会分散到其他链路，只会丢弃。在这种一台服务器接收流量超大的情况下，目的MAC地址负载均衡就不合理了。而根据源MAC地址负载均衡更为合适。

    另一点需要记住的是，负载均衡算法只适用于EtherChannel上发送的报文。它并没有双向功能。在交换机A上使用基于源MAC地址的算法可能比较合适，但对于交换机B不一定合适，因为email服务器是使用最多的服务器。当报文从email服务器返回，源MAC地址就是它自己本身。因此，如果我们在交换机B上使用基于源MAC地址的负载均衡算法，就会碰到一开始同样的问题。

    这种情况下，解决方法是在交换机A使用基于源MAC地址的负载均衡算法，而在交换机B使用目的MAC地址的算法。如果所有服务器在一台交换机而所有用户在另一台，这一解决方案是有效的。但现实中更常见的情况是所有这些设备都连接在一台交换机上，这时就没那么走运了。

    下图显示了一个比较有趣的问题。一台服务器通过EtherChannel连接到交换机A，一台NAS也通过EtherChannel连接到交换机A。服务器的所有文件系统都挂在到NAS设备上，服务器作为一台服务超过5000人的数据库服务器负载很大。服务器和NAS之间的带宽需求超过2Gbps。

    目前没有解决这一问题的简单的方法。不能使用源MAC地址或目的MAC地址做负载均衡，因为每种情况都只有一个地址。同样的理由，也不能用源和目的MAC地址结合，源和目的IP地址结合的方法。也不能基于源或目的端口号，因为一旦协商结束后，它们就不会改变。一种可能的方法是，驱动支持的情况下，改变服务器和/或NAS设备，每一个link都有自己的MAC地址，但是报文还是会从其中一个地址发出另一个地址接收。

    唯一的解决方法是手动负载均衡或采用更快的链接。将链路分为4个1Gbps，每一个有自己的IP网络，每个连接mount挂载不同的文件系统可以解决这一问题。有点太过复杂的话，直接使用更快的物理连接，如10 Gbps。

  • 路由器

    路由器

    介绍

    以太网交换机工作在第二层即数据链路层，用于在同一网络内部转发以太网帧。但是，当源和目的IP地址位于不同网络时，以太网帧必须发送给路由器。路由器负责在不同网络间传输报文，通过路由表来决定最佳转发路径。当主机将报文发送至不同IP地址时，由于主机无法直接与本地网络以外的设备通信，报文被转发至默认网关。默认网关就是数据流从本地网络路由至远端设备的目的地。它通常用来连接本地网与公共网。

    更多信息

    报文转发过程:

    路由器在一个接口接收报文并将它从另一个接口转发出去，这一过程的关键步骤是为输出链路将报文封装在适当的数据链路帧中。路由器主要执行以下三个步骤：

    1. 将第二层的帧头和帧尾移除，解析出第三层报文。
    2. 检查IP报文的目的IP地址，在路由表中查找最佳路由。
    3. 如果路由器找到一条最佳路径，则将三层报文封装到新的二层帧中，并将帧转发到输出端

    如下图所示：设备有三层IPv4地址，以太网接口有二层数据链路地址。例如PC 1的IPv4地址192.168.1.10，示例MAC地址0A-10。在报文从原设备传输至目的设备的过程中，三层IP地址不会改变。但是，每一跳随着报文在路由器中被解封装和重新封装，二层数据链路地址都会改变。很可能报文被封装成与接收时不同的另一种类型的二层帧。

    发送报文：

    PC 1发送报文给PC 2时，首先必须确定目的IPv4地址是否位于同一网络。PC 1通过将自己的IPv4地址与子网掩码做与操作，来判断PC 1所属的网段。接下来，PC 1对目的IPv4地址与PC1的子网掩码做同样的与操作。如果目的网络地址与PC 1网络相同，则PC 1不使用默认网关，而是在ARP缓存中查找目的IPv4地址的设备MAC地址。如果MAC地址不在缓存中，则PC1产生一个ARP请求来获取地址并将报文发给目的地址。如果目的网络地址位于另一网络，则PC 1将报文转发至默认网关。

    要确定默认网关的MAC地址，PC 1在它的ARP表中查找默认网关的IPv4地址以及相应的MAC地址。如果ARP表中没有默认网关的对应表项，则PC 1发送ARP请求。路由器R1回复ARP响应。之后PC 1将报文转发至默认网关的MAC地址，即路由器R1的Fa0/0接口。

    转发至下一跳

    R1从PC 1接收到以太网帧后执行以下步骤：

    1. R1检查目的MAC地址，与接收端口FastEthernet 0/0相匹配，因此，将帧复制到buffer。
    2. R1识别以太网类型为0x800，意味着以太网帧的数据部分包含IPv4报文。
    3. R1解封装该以太网帧。
    4. 由于目的IPv4地址与R1直连的任何网络都不相符，R1在路由表中查找包含该目的IPv4地址主机的网络地址。本例中，路由表中有192.168.4.0/24网络的路由。目的IPv4地址为192.168.4.10，即该网络上的主机IPv4地址。

    R1找到192.168.4.0/24路由的下一条IPv4地址为192.168.2.2以及输出端口FastEthernet 0/1，这意味着IPv4报文封装到一个新的以太网帧中，目标MAC地址是下一跳路由器的MAC地址。

    由于下一个接口是在以太网上，所以R1必须用ARP解析出下一跳IPv4地址的MAC地址。

    1. R1在ARP cache中查找下一跳IPv4地址192.168.2.2。如果表项不在ARP cache中，R1会从FastEthernet 0/1 接口发送ARP请求，R2会返回ARP响应。R1之后在ARP cache中更新192.168.2.2的MAC地址。
    2. IPv4报文封装到新的以太网帧中并从R1的FastEthernet 0/1 接口转发出去。

    到达目的地：

    当帧到达R3时执行以下步骤：

    1. R3将数据链路帧复制到它的buffer。
    2. R3解封装该数据链路帧。
    3. R3在路由表中查找该目的IPv4地址。R3路由表中有直接连接到该网络的路由。这表示报文可直接发送到目的设备而无需发送至路由器。

    由于输出接口是一个直连以太网，所以R3必须用ARP解析出目的IPv4地址的MAC地址。

    1. R3在它的ARP cache中查找目的IPv4地址，如果此ARP cache中没有此表项，R3会从FastEthernet 0/0 接口发送ARP请求。PC 2回复ARP响应告知它的MAC地址。R3之后在ARP cache中更新192.168.4.10的MAC地址。
    2. IPv4报文封装到新的以太网帧中并从R3的FastEthernet 0/0 接口发出。
    3. 当PC 2接收到该帧，检查帧的目的MAC地址，与网卡接收端口的MAC地址相匹配，PC 2于是将帧的剩余部分复制到自己的buffer。
    4. PC 2识别到以太网类型为0x800，也就是帧的数据部分包含IPv4报文。
    5. PC 2解封装以太网帧，将IPv4报文传递给操作系统的IPv4进程。

    路由表:

    路由表存储的信息包括：

    • 直连路径：来自活动路由接口的路径。当接口为活动状态并配置了IP地址时，路由器添加一条直连路径。
    • 远端路径：远端的网络连接到其他路由。通过静态配置或动态路由协议到达该网络。

    路由表是存储在RAM中的一份数据文件，用于存储直连以及远端网络的路由信息。路由表中包含网络或下一跳地址的信息。这些信息告知路由器可以通过将报文发送至代表下一跳地址的路由器以最佳路劲到达目的地址。下一跳信息也可以是到下一个目的地的输出接口。

    路由表内容：

    Cisco IOS路由器可用show IP route命令显示IPv4路由表。路由器还提供一些额外的路由信息，包括路径是怎样学习到的，路径在表中有多长时间，使用哪一接口去到达预定义的目的地。

    路由表中的表项可作为以下内容添加：

    • 本地路径接口：当接口配置并激活时添加。
    • 直连接口：当接口配置并激活时添加。
    • 静态路径：当手动配置路径并且输出接口激活时。
    • 动态路由协议：当路由协议动态学习到网络时添加，如EIGRP或OSPF。

    路由表项的来源通过代码来标识，代码表明路径是怎样学习到的。例如，常用代码包括：

    L：路由器接口地址。当路由器接收到报文时发送至本地接口而无需转发。
    C：直连网段。
    O：通过OSPF从另一个路由器动态学习到的网络。
    D：通过EIGRP从另一个路由器动态学习到的网络。

    下图显示了R1的路由表：

    远端网络路由表项：

    下图显示了R1到远端网络10.1.1.0的表项：

    • Route source：路径是怎样学习到的。
    • Destination network：远端网络地址。
    • Administrative distance：路由来源的可信度。较低值表明优先选择。
    • Metric：是路由算法用以确定到达目的地的最佳路径的计量标准。较低值表明优先选择。
    • Next hop：转发报文的下一个路由器的IP地址。
    • Route timestamp：自学习到路径以来过了多少时间。
    • Outgoing interface：用以转发报文的输出接口。

    直连路由表项：

    下图显示了R1到直连网络192.168.10.0的路由表项：

    在一个接口状态为up/up并添加到IPv4路由表之前，接口必须：

    • 指定有效的IPv4或IPv6地址。
    • 通过no shutdown命令激活。
    • 从另一设备（路由器，交换机，主机等）接收到载体信号。

    当接口up之后，该接口的网络作为直连网络添加到路由表中。

    静态路由:

    静态路由是指由网络管理员手动配置在路由器上的表项。对于特定的目标地址，以及在小型或稳定的网络环境，手动配置静态路由可以非常成功地应用。通过使用静态路由，网络管理员确定了通向一目标网络的路径。

    一个重要的概念是：路由的核心在于下一跳。下一跳是一个特定路由器的角度来看，距离目标地址更近一步的路由器。下图显示了一个中型路由拓扑。从R1的角度来看，R2同时是到达192.168.3.0以及192.168.4.0的下一跳。

    初始状态下，除了已经启动的接口和给定的IP地址以外，什么都没有配置。路由器的路由表只会包含直连路由。每一个路由器只知道它接口相连的两个网络。下表显示了这一时刻的路由表。

    从上表可以看出，路由器不知道整个网络的情况。例如，Node A连接到Switch 1尝试访问Switch 4的Node B。经过主机路由表处理后，A将数据转发至R1的默认网关（192.168.1.254），R1查询自己的路由表并发现没有目标网络的相关信息。于是R1发送ICMP destination unreachable消息。

    这个问题怎么解决呢？像这样的小型网络，网络管理员可以在路由器输入路由命令，配置额外的转发信息：

    例如，以下命令告知R1怎样到达192.168.3.0以及192.168.4.0：

    ip route 192.168.3.0 255.255.255.0 192.168.2.254
ip route 192.168.4.0 255.255.255.0 192.168.2.254

    R1上输入命令之后，路由表更新如下所示：

    现在R1理解到达这些网络需要经过R2，但是R2接下来怎么办呢?由于192.168.3.0直接连接到R2，R2可以直接ARP主机。但对于192.168.4.0，R2需要管理员以下命令来协助：

    ip route 192.168.4.0 255.255.255.0 192.168.3.254

    路由表相应更新：

    目前只成功了一半，报文需要返回。查看R3的路由表，发现路由器不知道怎么找到192.168.1.0。Node A的报文到达之后，Node B尝试回复，但是会从R3收到ICMP destinationunreachable的消息。在Node A看来，好像传输从未收到回复。要完成这一过程，需要在所有路由器上对于所有未知网络输入ip route命令来更新路由表。

    R2真正的路由表以及在R2上输入的ip route命令如下图所示：

    动态路由:

    路由协议允许路由器动态共享远端网络的信息以及自动将这信息添加到自己的路由表中。动态路由协议的一大好处在于当拓扑变更时，路由器会交换路由信息，从而能够自动学习新增网络，并且在链路故障时，找到替换路径。

    路由协议完成这一功能的方式取决于它所使用的算法以及此协议的操作特性。通常来说，动态路由协议的执行过程如下：

    1. 路由器在端口发送和接收路由消息。
    2. 路由器与其他使用相同路由协议的路由器共享路由信息。
    3. 路由器交换路由信息来学习远端网络。
    4. 当路由器检测到拓扑变化时，路由协议将这一变化通知其他路由器

    网络发现

    例如，R1，R2，R3之间的拓扑：

    R1：发送10.1.0.0以及10.2.0.0的更新；从R2接收10.3.0.0的信息，跳数加1；在路由表中存储10.3.0.0的信息，metric设为1。
    R2：发送10.3.0.0以及10.2.0.0的更新；从R1接收10.1.0.0的信息，跳数加1；在路由表中存储10.1.0.0的信息，metric设为1。从R3接收10.4.0.0的信息，跳数加1；在路由表中存储10.4.0.0的信息，metric设为1。
    R3：发送10.3.0.0以及10.4.0.0的更新；从R2接收10.2.0.0的信息，跳数加1；在路由表中存储10.2.0.0的信息，metric设为1。

    交换路由信息

    路由器周期性的更新信息。在最初的网络发现结束后，每个路由器通过发送和接收以下更新来继续收敛的过程：

    R1：发送10.1.0.0，10.2.0.0以及10.3.0.0的更新；从R2接收10.4.0.0的信息，跳数加1；在路由表中存储10.4.0.0的信息，metric设为2；从R2收到相同的10.3.0.0的更新，metric为1，不作更新。
    R2：发送10.1.0.0，10.2.0.0，10.3.0.0以及10.4.0.0的更新；从R1接收10.1.0.0的信息，不作更新；从R3接收10.4.0.0的信息，不作更新。
    R3：发送10.2.0.0，10.3.0.0以及10.4.0.0的更新；从R2接收10.1.0.0的信息，跳数加1；在路由表中存储10.1.0.0的信息，metric设为2；从R2收到相同的10.2.0.0的更新，metric为1，不作更新。

    距离矢量路由协议切断了邻居路由之间的环路，也称为水平分割。水平分割阻止信息从同一端口接收之后再发送出去。例如，R2不会从Serial 0/0/0端口发送网络10.1.0.0的信息，因为R2从Serial 0/0/0学习了10.1.0.0。

    网络中的路由器收敛了信息之后，路由器可以使用路由表来决定到达目的地的最佳路径。不同的路由协议有不同的计算最佳路径的方法。

    路由收敛

    当所有路由器对于整个网络有准确的更新之后，达到路由收敛状态，如下图所示：

    收敛时间是路由器分享信息，计算最佳路径，更新路由表的时间。收敛同时是协作并且独立的。路由器相互之间共享信息但是必须各自独立的计算自己路由拓扑改变所带来的影响。 由于它们各自独立地关于新的拓扑达成一致，于是说它们收敛于这种一致。