标签：
从之前介绍的网络层协议来看，通信的两端是两台主机，IP 数据报首部就标明了这两台主机的 IP 地址。但是从传输层来看，是发送方主机中的一个进程与接收方主机中的一个进程在交换数据，因此，严格地讲，通信双方不是主机，而是主机中的进程。
主机中常常有多个应用进程同时在与外部通信(比如你的浏览器和 QQ 在同时运行)，下图中，A 主机的 AP1 进程在于 B 主机的 AP3 进程通信，同时主机 A 的 AP2 进程也在与 B 主机的 AP4 进程通信。
两个主机的传输层之间有一个灰色双向箭头，写着“传输层提供应用进程间的逻辑通信”。 逻辑通信：看起来是数据似乎是沿着双向箭头在传输层水平传输的，但实际上是沿图中的虚线经多个协议层次而传输。
TCP/IP 协议栈传输层有两个重要协议——UDP 和 TCP，不同的应用进程在传输层使用 TCP 或 UDP 之一：
在第一节我们已经了解过端口的概念，端口的作用体现在传输层。
刚才的图中，AP1 与 AP3 的通信与 AP2 与 AP4 的通信可以使用同一个传输层协议来传输(TCP 或 UDP)，根据 IP 地址或 MAC 地址都只能是把数据传到正确的主机，但具体需要传到哪一个进程，是通过端口来辨认的。比如同时使用浏览器和 QQ，浏览器占用 80 端口，而 QQ 占用 4000 端口，那么发送过来的 QQ 消息便会通过 4000 端口显示在 QQ 客户端，而不会错误地显示在浏览器上。
端口号有 0～65535 的编号，其中：
| 应用层协议： | FTP | TELNET | SMTP | DNS | TFTP | HTTP | SNMP |
|---|---|---|---|---|---|---|---|
| 系统端口号： | 21 | 23 | 25 | 53 | 69 | 80 | 161 |
编号 1024～49151 为 登记端口号 ，为没有系统端口号的应用程序使用，使用这类端口号必须在 IANA 按规定手续登记，以防止重复。
编号 49152～65535 为 短暂端口号 ，是留给客户进程选择暂时使用的，使用结束后，这类端口号会被放开以供其它程序使用。
UDP(User Datagram Protocol)用户数据报协议，它只在 IP 数据报服务之上增加了很少一点功能，它的主要特点有：
(1).UDP 是无连接的，发送数据之前不需要建立连接(而 TCP 需要)，减少了开销和时延。
(2).UDP尽最大努力交付，不保证交付可靠性。
(3).UDP 是面向报文的，对于从网络层交付下来的 IP 数据报，只做很简单的封装(8 字节 UDP 报头)，首部开销小。
(4).UDP 没有拥塞控制，出现网络拥塞时发送方也不会降低发送速率。这种特性对某些实时应用是很重要的，比如 IP 电话，视频会议等，它们允许拥塞时丢失一些数据，因为如果不抛弃这些数据，极可能造成时延的累积。
(5).UDP 支持一对一、一对多、多对一和多对多的交互通信。
从应用层到传输层，再到网络层的各层次封装：
UDP 数据报可分为两部分：UDP 报头和数据部分。其中数据部分是应用层交付下来的数据。UDP 报头总共 8 字节，而这 8 字节又分为 4 个字段：
(1)源端口 2 字节 在对方需要回信时可用，不需要时可以全 0；
(2)目的端口 2 字节 必须，也是最重要的字段；
(3)长度 2 字节 长度值包括报头和数据部分；
(4)校验和 2 字节 用于检验 UDP 数据报在传输过程中是否有出错，有错就丢弃。
现在我们动手实践，尝试抓取一个 UDP 数据报，并解读其内容。
我们需要一个小程序，用于向 指定 IP 地址 的 指定端口 发送一个 指定内容 的 UDP 数据报，这个程序已经编写好，依次输入以下命令，使用 github 把它下载下来，并编译：
cd Desktop
git clone http://git.shiyanlou.com/shiyanlou/tcp_ip_5
cd tcp_ip_5
gcc -o test test.c
这个 C 程序会向 IP 地址 192.168.1.1 的 7777 端口 发送一条 "hello" 消息。你可以用编辑器修改程序，向不同的 IP 不同的 IP 发送不同的内容。
编译完成后先别运行，我们还需要使用一个知名的抓包工具 tcpdump ，依次输入以下命令安装，并运行 tcpdump：
sudo apt-get update
sudo apt-get install tcpdump
sudo tcpdump -vvv -X udp port 7777
现在最小化当前终端，另开启一个终端，输入以下命令运行刚才编译好的 C 程序 test：
cd Desktop/tcp_ip_5
./test
test 程序运行结束，返回刚才运行 tcpdump 的终端查看抓包结果：
TCP 和 UDP 处在同一层——运输层，但是它们有很多的不同。TCP 是 TCP/IP 系列协议中最复杂的部分，它具有以下特点：
(1) TCP 提供 可靠的 数据传输服务，TCP 是 面向连接的 。应用程序在使用 TCP 通信之前，先要建立连接，这是一个类似“打电话”的过程，通信结束后还要“挂电话”。
(2) TCP 连接是 点对点 的，一条 TCP 连接只能连接两个端点。
(3) TCP 提供可靠传输，无差错、不丢失、不重复、按顺序。
(4) TCP 提供 全双工 通信，允许通信双方任何时候都能发送数据，因为 TCP 连接的两端都设有发送缓存和接收缓存。
(5) TCP 面向 字节流 。TCP 并不知道所传输的数据的含义，仅把数据看作一连串的字节序列，它也不保证接收方收到的数据块和发送方发出的数据块具有大小对应关系。
TCP 是面向字节流的，而 TCP 传输数据的单元是 报文段 。一个 TCP 报文段可分为两部分：报头和数据部分。数据部分是上层应用交付的数据，而报头则是 TCP 功能的关键。
TCP 报文段的报头有前 20 字节的固定部分，后面 4n 字节是根据需要而添加的字段。如图则是 TCP 报文段结构：
20 字节的固定部分，各字段功能说明：
1.源端口和目的端口:各占 2 个字节，分别写入源端口号和目的端口号。这和 UDP 报头有类似之处，因为都是运输层协议。
2.序号:占 4 字节序，序号范围[0，2^32-1]，序号增加到 2^32-1 后，下个序号又回到 0。 TCP 是面向字节流的，通过 TCP 传送的字节流中的每个字节都按顺序编号，而报头中的序号字段值则指的是本报文段数据的第一个字节的序号。
3.确认序号:占 4 字节，期望收到对方下个报文段的第一个数据字节的序号。
4.数据偏移:占 4 位，指 TCP 报文段的报头长度，包括固定的 20 字节和选项字段。
5.保留:占 6 位，保留为今后使用，目前为 0。
6.控制位:共有 6 个控制位，说明本报文的性质，意义如下：
**URG 紧急**:当 URG=1 时，它告诉系统此报文中有紧急数据，应优先传送(比如紧急关闭)，这要与**紧急指针**字段配合使用。
**ACK 确认**:仅当 ACK=1 时**确认号**字段才有效。建立 TCP 连接后，所有报文段都必须把 ACK 字段置为 1。
**PSH 推送**:若 TCP 连接的一端希望另一端立即响应，PSH 字段便可以“催促”对方，不再等到缓存区填满才发送。
**RET 复位**:若 TCP 连接出现严重差错，RST 置为 1，断开 TCP 连接，再重新建立连接。
**SYN 同步**:用于建立和释放连接，稍后会详细介绍。
**FIN 终止**:用于释放连接，当 FIN=1，表明发送方已经发送完毕，要求释放 TCP 连接。
7.窗口:占 2 个字节。窗口值是指发送者自己的接收窗口大小，因为接收缓存的空间有限。
8.检验和:2 个字节。和 UDP 报文一样，有一个检验和，用于检查报文是否在传输过程中出差错。
9.紧急指针:2 字节。当 URG=1 时才有效，指出本报文段紧急数据的字节数。
10.选项:长度可变，最长可达 40 字节。具体的选项字段，需要时再做介绍。
刚才说过，TCP 是面向连接的，在传输 TCP 报文段之前先要创建连接，发起连接的一方被称为客户端，而响应连接请求的一方被称为服务端，而这个创建连接的过程被称为三次握手 ：
(1) 客户端发出请求连接报文段，其中报头控制位 SYN=1，初始序号 seq=x。客户端进入 SYN-SENT(同步已发送)状态。
(2) 服务端收到请求报文段后，向客户端发送确认报文段。确认报文段的首部中 SYN=1，ACK=1，确认号是 ack=x+1，同时为自己选择一个初始序号 seq=y。服务端进入 SYN-RCVD(同步收到)状态。
(3) 客户端收到服务端的确认报文段后，还要给服务端发送一个确认报文段。这个报文段中 ACK=1，确认号 ack=y+1，而自己的序号 seq=x+1。这个报文段已经可以携带数据，如果不携带数据则不消耗序号，则下一个报文段序号仍为 seq=x+1。
至此 TCP 连接已经建立，客户端进入 ESTABLISHED(已建立连接)状态，当服务端收到确认后，也进入 ESTABLISHED 状态，它们之间便可以正式传输数据了。
当传输数据结束后，通信双方都可以释放连接，这个释放连接过程被称为 释放连接 :
(1) 此时 TCP 连接两端都还处于 ESTABLISHED 状态，客户端停止发送数据，并发出一个 FIN 报文段。首部 FIN=1，序号 seq=u（u 等于客户端传输数据最后一字节的序号加 1）。客户端进入 FIN-WAIT-1(终止等待 1)状态。
(2) 服务端回复确认报文段，确认号 ack=u+1，序号 seq=v（v 等于服务端传输数据最后一字节的序号加 1），服务端进入 CLOSE-WAIT(关闭等待)状态。现在 TCP 连接处于半开半闭状态，服务端如果继续发送数据，客户端依然接收。
(3) 客户端收到确认报文，进入 FIN-WAIT-2 状态，服务端发送完数据后，发出 FIN 报文段，FIN=1，确认号 ack=u+1，然后进入 LAST-ACK(最后确认)状态。
(4) 客户端回复确认确认报文段，ACK=1，确认号 ack=w+1（w 为半开半闭状态时，收到的最后一个字节数据的编号） ，序号 seq=u+1，然后进入 TIME-WAIT(时间等待)状态。
注意此时连接还没有释放，需要时间等待状态结束后(4 分钟) 连接两端才会 CLOSED。设置时间等待是因为，有可能最后一个确认报文丢失而需要重传。
(1) TCP 报文段的长度可变，根据收发双方的缓存状态、网络状态而调整。
(2) 当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。
(3) 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段，如果不能及时收到一个确认，将重发这个报文段。这就是稍后介绍的超时重传。
(4) TCP 将保持它首部和数据的检验和。如果通过检验和发现报文段有差错，这个报文段将被丢弃，等待超时重传。
(5) TCP 将数据按字节排序，报文段中有序号，以确保顺序的正确性。
(6) TCP 还能提供流量控制。TCP 连接的每一方都有收发缓存。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。
可见超时重发机制是 TCP 可靠性的关键，只要没有得到确认报文段，就重新发送数据报，直到收到对方的确认为止。
TCP 规定，接收者收到数据报文段后，需回复一个确认报文段，以告知发送者数据已经收到。而发送者如果一段时间内(超时计时器)没有收到确认报文段，便重复发送：
为了实现超时间重传，需要注意：
1.发送者发送一个报文段后，暂时保存该报文段的副本，为发生超时重传时使用，收到确认报文后删除该报文段。
2.确认报文段也需要序号，才能明确是发出去的那个数据报得到了确认。
3.超时计时器比传输往返时间略长，但具体值是不确定的，根据网络情况而变。
也许你也发现了，按上面的介绍，超时重传机制很费时间，每发送一个数据报都要等待确认。
在实际应用中的确不是这样的，真实情况是，采用了流水线传输：发送方可以连续发送多个报文段(连续发送的数据长度叫做窗口)，而不必每发完一段就停下来等待确认。
实际应用中，接收方也不必对收到的每个报文都做回复，而是采用累积确认方式：接收者收到多个连续的报文段后，只回复确认最后一个报文段，表示在这之前的数据都已收到。
这样，传输效率得到了很大的提升。
由于接收方缓存的限制，发送窗口不能大于接收方接收窗口。在报文段首部有一个字段就叫做窗口(rwnd)，这便是用于告诉对方自己的接收窗口，可见窗口的大小是可以变化的。
那么窗口的大小是如何变化的呢？TCP 对于拥塞的控制总结为“慢启动、加性增、乘性减”，如图所示：
(1) 慢启动 ：初始的窗口值很小，但是按指数规律渐渐增长，直到达到慢开始门限(ssthresh)。
(2) 加性增 ：窗口值达到慢开始门限后，每发送一个报文段，窗口值增加一个单位量。
(3) 乘性减 ：无论什么阶段，只要出现超时，则把窗口值减小一半。
上一节实验，我们用 tcpdump 抓取并阅读了 UDP 报文，那么这次我们尝试抓取 TCP 报文段。当然首先要安装 tcpdump(安装方法参考上一节实验)。
针对这次实验，需要下载从 github 下载代码，是基于 TCP 的聊天小程序，分为 server(服务端)和 client(客户端)：
cd Desktop
git clone http://git.shiyanlou.com/shiyanlou/tcp_ip_6
cd tcp_ip_6
gcc -o server server.c
gcc -o client client.c
编译完成后先不要运行，先打开 tcpdump，使用命令安装并运行 tcpdump：
sudo apt-get update
sudo apt-get install tcpdump
sudo tcpdump -vvv -X -i lo tcp port 7777
最小化运行 tcpdump 的终端，然后另开一个终端，运行 server 程序：
cd Desktop/tcp_ip_6
./server 127.0.0.1
然后再打开第三个终端，运行 client 程序：
cd Desktop/tcp_ip_6
./client 127.0.0.1
现在，使用 client 和 server 聊天，轮流互发几条简短的消息(比如 hello、hi、wei 之类的)便可以关闭 client 和 server，回到运行 tcpdump 的终端查看抓取的报文段内容：
通过抓取的报文，还可以清晰的看到建立连接三次握手和断开连接四次握手的过程。
标签：
原文地址：http://blog.csdn.net/sunansheng/article/details/52056125
