TCP/IP入门

---

一，OSI网络分成介绍

网络结构的标准模型是OSI模型，它是由国际互联网标准化组织（International Organization for Standardization，ISO）定义的网络分层模型。虽然目前没有完全按照这种模型实现的网络协议栈，但是这种模型对于理解网络协议内部的架构很有帮助，为学习网络协议栈提供了很好的参考模型。这个模型一般称为ISO/OSI开放互联模型，在实际中TCP/IP协议栈更为广泛。

ISO/OSI开放互联模型采用7层结构，如图

在OSI的7层模型结构中，从纵向即单个主机的角度来看，每一层与本层的上下两层从逻辑上是分开的，例如A的网络层和数据链路层是分开的。这种方式使得每一层为上一层提供服务，依赖于下层的数据并为上一层提供接口。同时各层之间的规则是相互独立的，例如数据的格式、通信的方式等，这称为本层的协议。

不同主机相同层之间是对等的，例如主机A中的应用层和主机B中的应用层是相同的层次，这两个层互为对等层，对等层之间的规则是一致的，但实现不一定相同。例如，UNIX网络协议栈运行在主机A上，Windows的网络协议栈运行在主机B上，只要它们的规则一致就可以；例如A上的FTP服务器可以与B上的FTP客户端实现互相通信。

一个主机上运行的网络规则实现的集合称为协议栈，主机利用协议栈来接受和发送数据。ISO/OSI的7层网络结构模型可以将网络协议栈的不同层的实现划分为不同的层次，将问题简化，方便网络协议栈的实现。同时，7层模型为网络中不同厂商的软硬件产品的兼容性提出了解决的方法。由于7层模型的方式实现起来太复杂，所以并没有一个实际使用的7层网络协议栈。

---

二，TCP/IP协议栈

由于ISO制定的OSI参考模型过于庞大、复杂，在实现时造成了很多困难，从而招致了很多批评。实际实现中，TCP/IP协议栈获得了更为广泛的应用，目前主流的操作系统网络协议栈基本上都采用了TCP/IP协议栈。

经典的TCP/IP参考模型从上至下分为4个层次：应用层、传输层、网络层和主机到网络层。与OSI模型不同的是在TCP/IP参考模型中，根据实际情况将OSI参考模型的会话层和表示层合并到应用层中；同时，将OSI参考模型中的数据链路层和物理层合并为主机到网络层。TCP/IP参考模型与OSI参考模型的对照如图。

实际应用中TCP/IP的层次结构如图。

各层的主要功能如下：
主机到网络层：包括设备和数据链路层的主机到网络层，在TCP/IP参考模型中并没有描述这一层的具体实现，只是规定能给其上一层的网络互联层提供的接口，可以传输IP数据包，这一层的具体实现随着网络类型的不同而不同。
网络互联层：网络互联层是整个TCP/IP协议栈的核心。它将数据包进行分组并发往目的主机或网络，为了尽快地发送分组，一个数据包的分组可能要经过不同的路径进行传递。这造成了分组之间到达目的网络或者主机的顺序不是原来发送分组的顺序，需要在本层对分组进行排序。网络互联层定义了数据包的分组格式和协议，IP协议（Internet Protocol），因此网络互联层又经常称为IP层。网络互联层的功能有路由、网际互联和拥塞控制等。
传输层：TCP/IP参考模型中传输层的功能提供源主机和目标主机上的对等层之间可以进行会话的机制。在传输层中定义了两种协议，传输控制协议（transmission control protocol，TCP）和用户数据报协议（user datagram protocol，UDP）。TCP协议是一个面向连接的、可靠的协议。它利用IP层的机制在不可靠连接的基础上实现可靠的连接，通过发送窗口控制、超时重发、发包等方法，将一台主机发出的字节流发往互联网上的其他主机。UDP协议是一个不可靠的、无连接协议，主要适用于不怕数据丢失、不需要对报文进行排序、流量控制的场景。
应用层：TCP/IP参考模型中把OSI参考模型中的会话层和表示层取消，其功能被合并到应用层。基于TCP和UDP实现了很多的应用层协议，例如基于TCP协议的文件传输协议（File Transfer Protocol，FTP）、Telnet协议、超文本链接协议（Hyper Text Transfer Protocol，HTTP）等，基于UDP的协议有简化的FTP协议TFTP、网络管理协议SNMP、域名服务DNS、网络文件共享NFS和SAMBA等，以及两种方式均有实现的协议，例如目前应用十分广泛的多种P2P协议（BitTorrent、eMule等）。

---

三，TCP原理

1，TCP套接字中I/O缓存

假设客户端和服务端都是通过read和write函数读取和传输数据的。
TCP套接字的数据收发无边界。服务器即使调用1次write函数传输40字节的数据，客户端也有可能通过4次read函数调用每次读取10字节。但此处也有一些疑问，服务器一次性传输40字节，而客户端居然可以缓慢地分批接受。客户端接受10字节后，剩下的30字节在何处等候呢？
实际上，write函数调用后并非立即传输数据，read函数调用后也并非马上接受数据。更准确地说，如图5-2所示，write函数调用瞬间，数据将移至输出缓冲；read函数调用瞬间，从输入缓冲读取数据。

如图5-2所示，调用write函数时，数据将移到输出缓冲中，在适当的时候（不管是分别传送还是一次性传送）传向对方的输入缓冲。这时对方讲调用read函数从输入缓冲读取数据。这些I/O缓冲特性整理如下。

• I/O缓冲在每个TCP套接字中单独存在。
• I/O缓冲在创建套接字时自动生成。
• 即使关闭套接字也会继续传递输出缓冲中遗留的数据。
• 关闭套接字将丢失输入缓冲中的数据。

这时存在一个问题，如果客户端的输入缓冲为50字节，而服务端传输了100字节，就会导致传输的数据量大于客户端的输入缓冲的字节数。

但是实际上，不会发生超过输入缓冲大小的数据传输。因为TCP会控制数据流。TCP中有滑动窗口（Sliding Window）协议，用对话方式呈现如下。

套接字A：“你好，最多可以向我传递50字节”。
套接字B：“OK。”

套接字A：“我腾出了20字节的空间，最多可以收70字节。”
套接字B：“OK。”

数据收发也是如此，因此TCP中不会因为缓冲溢出而丢失数据。

2，与对方套接字的连接

TCP套接字从创建到消失所经过程分为如下3步。

• 与对方套接字建立连接。
• 与对方套接字进行数据交换。
• 断开与对方套接字的连接。

首先讲解与对方套接字建立连接的过程。连接过程中套接字之间的对话如下。

• 【Shake 1】套接字A：“你好，套接字B。我这儿有数据要传给你，建立连接吧。”
• 【Shake 2】套接字B：“好的，我这边已就绪。”
• 【Shake 3】套接字A：“谢谢你受理我的请求。”

TCP在实际通信过程中也会经过3次对话过程，因此，该过程又称Three-way handshanking（三次握手）。连接过程中实际交换的信息格式，如图5-3所示。

套接字时以全双工（Full-duplex）方式工作的。也就是说，它可以双向传递数据。因此，收发数据前需要做一些准备。首先，请求连接的主机A向主机B传递如下信息：

[SYN] SEQ:1000,ACK:-

该消息中SEQ为1000，ACK为空，而SEQ为1000的含义如下：

先传递的数据包序号为1000，如果接收无误，请通知我向您传递1001号数据包。

这是首次请求连接时使用的消息，又称SYN。SYNC是Synchronization的简写，表示收发数据前传输的同步信息。接下来主机B向A传递如下消息：

[SYN+ACK] SEQ:2000,ACK:1001

此时SEQ为2000，ACK为1001，而SEQ为2000的含义如下：

先传递的数据包序号为2000，如果接收无误，请通知我向您传递2001号数据包。

而ACK为1001的含义如下：

刚才传输的SEQ为1000的数据包接收无误，现在请传递SEQ为1001的数据包。

对主机A首次传输的数据包的确认消息（ACK 1001）和为主机B传输数据准备的同步消息（SEQ 2000）捆绑发送因此，这种类型的消息又称SYN+ACK。
收发数据前向数据包分配序号，并向对方通报此序号，这都是为了防止数据丢失所做的准备。通过向数据包分配序号并确认，可以在数据丢失时马上查看并重传丢失的数据包。因此，TCP可以保证可靠的数据传输。最后观察主机A箱主机B传输的信息：

[ACK] SEQ:1001,ACK:2001

TCP连接过程中发送数据包时需分配序号。在之前的序号1000基础上加1，也就是分配1001.此时该数据包传递如下信息：

已正确收到传输的SEQ为2000的数据包，现在可以传输SEQ为2001的数据包。

这样就传输了添加ACK 2001的ACK信息。至此，主机A和主机B确认了彼此均就绪。

3，与对方主机的数据交换

通过第一步三次握手过程完成了数据交换准备，下面就正式开始收发数据，其默认方式如图5-4所示。

图5-4给出了主机A分2次（分2个数据包）向主机B传递200字节的过程。首先，主机A通过1个数据包发送100字节的数据，数据包的SEQ为1200.主机B为了确认这一点，向主机A发送了ACK1301消息。
此时的ACK序号为1301而非1201，原因在于ACK号的增量为传输的数据字节数。假设每次ACK号不加传输的字节数，这样虽然可以确认数据包的传输，但无法明确100字节全都正确传递还是丢失了一部分，比如只传递了80字节。因此按如下公式传递ACK消息：

ACK号 = SEQ号 + 传递的字节数 + 1

与三次握手协议相同，最后加1是为了告知对方下次要传递的SEQ号。下面分析传输过程中数据包消失的情况，如图5-5所示。

图5-5表示通过SEQ 1301数据包向主机B传递100字节数据。但中间发生了错误，主机B未收到。经过一段时间后，主机A仍未收到对于SEQ 1301的ACK确认，因此试着重传该数据包。为了完成数据包重传，TCP套接字启动计时器以等待ACK应答。若相应计时器发生了超时（Time-out）则重传。

4，断开与套接字的连接

TCP套接字的结束过程也非常优雅。如果对方还有数据需要传输时直接断掉连接会出问题，所以断开连接时需要双方协商。断开连接时双方对话如下：

套接字A：“我希望断开连接。”
套接字B：“哦，是吗？请稍候。”

套接字B：“我也准备就绪，可以断开连接。”
套接字A：“好的，谢谢合作。”

先由套接字A向套接字B传递断开连接的信息，套接字B发出确认收到的消息，然后向套接字A传递可以断开连接的消息，套接字A同样发出确认消息，如图5-6所示。

图5-6数据包内的FIN表示断开连接。也就是说，双方各发送1次FIN消息后断开连接。此过程经历4个阶段，因此又称四次握手（Four-way handshaking）。SEQ和ACK的含义与上面的内容一致，故省略。图5-6中向主机A传递了两次ACK 5001，第二次FIN数据包中的ACK 5001只是因为接受ACK消息后未接受数据而重传的。

---

四，UDP原理

1，UDP套接字的特点

下面通过信件说明UDP的工作原理，这是讲解UDP时使用的传统示例，它与UDP特性完全相符。寄信前应先在信封上填好寄信人和收信人的地址，之后贴上邮票放进邮筒即可。当然，信件的特点使我们无法确认对方是否收到。另外，邮寄过程中也可能发生信件丢失的情况。也就是说，信件是一种不可靠的传输方式。与之类似，UDP提供的同样是不可靠的数据传输服务。

TCP是比UDP更优质的协议吗？如果只考虑可靠性，TCP的确比UDP好。但UDP在结构上比TCP更简洁。UDP不会发送类似ACK的应答消息，也不会像SEQ那样给数据包分配序号。因此，UDP的性能有时比TCP高出很多。编程中实现UDP也比TCP简单。另外，UDP的可靠性虽比不上TCP，但也不会像想象中那么频繁地发送数据损坏。因此，在更重视性能而非可靠性的情况下，UDP是一种很好的选择。

UDP的作用使什么？为了提供可靠的数据传输服务，TCP在不可靠的IP层进行流控制，而UDP就缺少这种流控制机制。

UDP和TCP的差异只要就在流控制机制。流控制是分区UDP和TCP的最重要标志。但若从TCP中除去流控制，所剩内容也屈指可数。也就是说，TCP的生命在于流控制。

2，UDP内部工作原理

与TCP不同，UDP不会进行流控制。如图6-1所示。

从图6-1中可以看出，IP的作用就是让离开主机B的UDP数据包传递到主机A。但把UDP包最终交给主机A的某一UDP套接字的过程则由UDP完成。UDP最重要的作用就是根据端口号将传到主机的数据包交付给最终的UDP套接字。

3，UDP的高效使用

虽然貌似大部分网络编程都基于TCP实现，但也有一些是基于UDP实现的。接下来考虑何时使用UDP更有效。UDP也具有一定的可靠性。网络传输特性导致信息丢失频发，可若要传递压缩文件（发送1万个数据包时，只要丢失1个就会产生问题），则必须使用TCP，因为压缩文件只要丢失一部分就很难解压。但通过网络实时传输视频或音频时的情况有所不同。对于多媒体而言，丢失一部分也没有太大问题，这只会引起短暂的画面抖动，或出现细微的杂音。但因为需要提供实时服务，速度就成为非常重要的因素。因此，流控制就显得有些多余，此时需要考虑使用UDP。但UDP并非每次都快于TCP，TCP比UDP慢的原因通常有以下两点。

• 收发数据前后进行的连接设置及清除过程。
• 收发数据过程中为保证可靠性而添加的流控制。

如果收发的数据量小但需要频繁连接时，UDP比TCP更高效。

---

五，参考资料

《Linux网络编程》
《TCP IP网络编程》