我们在前面讨论 OSI 和 TCP/IP 分层协定概念的时候﹐已经指出﹕不管协定设计者如何定义层级﹐各层级协定大致分成两类﹕网路群组和使用者群组。前面介绍的 ARP ﹑IP﹑RIP 等协定﹐可以算是网路群组的范围﹐假如您对前述概念都有一定认识﹐已经知道了一个封包如何从一个节点传递到另一个节点。然而﹐这仅是 TCP/IP 协定的一半而已﹐要完全了解 TCP/IP 的精髓﹐在 IP 协定的更上一个层级﹐属于使用者群组协定之一﹕TCP 协议﹐是不可不知道的。只有当我们同时把 IP 协议和 TCP 协议理解进来﹐才能完整的描述电脑与电脑之间的资料传送过程﹔也只有如此﹐我们才有把握进行日常的 TCP/IP 网路管理。TCP 与 IP 这对孪生兄弟﹐是每一个网路管理人员必须混熟的朋友。下面﹐我们将一起探讨在 TCP/IP 协议中举足轻重的传送层﹐是如何影响我们日常的网路资料传输的。
传送层的功能
在前面讨论网际网路层的时候﹐我们知道﹕网际网路层协议只提供路由资讯的判断﹐以确定封包的传送路径。但事实上 IP 协定只确保封包交换设备之间的传输﹐并没有提供一套机制来确保数据的传输。在低层的通讯里﹐封包可能在传送过程中发生错误﹐诸如网路硬体的损坏﹑网路负荷过重等等﹐导致封包被丢弃或损坏。由于封包路由的多样性和复杂性﹐以及影响路由因素众多及其不可预测性﹐封包之抵达常是不依序的﹐或是会发生重复传送的情形。因此﹐我们必须提供一套网路技术﹐以达成更可靠和有效的传送。
再者﹐ IP 封包的体积是有限的﹐然而﹐网路程式之间交换的数据往往会超过这个体积限制﹔那么﹐我们必须有另一套机制将程式送来的资料进行规划﹐以符合 IP 封包的传送要求。在高层的程式里﹐除非利用非可靠和非连线型(connectionless)的资料传送方式﹐否则，程式设计者必须对每一个一个应用程式处理侦错和修复的动作﹐这无疑增加了程式设计和修改的难度﹐而且也做成许多重复的处理动作。因此﹐我们也有必要找出一个可靠的资料流传送方法﹐以建立单独且适用于所有应用程序的资料传送协议。这样就可以将应用程式与网路内部协议隔离﹐同时提供一致的资料流传送界面。
传送层的设计可以说是应上述要求而生的﹐它的主要功能有﹕
- 接管由上层协定传来的资料﹐并以 IP 封包可以接受的格式进行“封装”工作。
- 进行资料传送和回应的确认﹐以及处理资料流的检测和控制。
- 对不同的连线进行追踪及转换。
在 TCP/IP 协议组中，关于传送层的协定就是 TCP 和 UDP 了﹐我们将在下面详细讨论。简而言之﹐TCP 提供的是一个可靠的资料流传送服务﹔相对而言﹐UDP 提供的是一个非可靠的非连线型(connectionless)的资料流传送服务。
可靠性传送服务的特性
在应用程式对 TCP 的可靠性传送服务之主要要求有五个﹕
- 资料流导向。处理程式之间的大量资料传送﹐确保双方的位元资料流之统一性。
- 虚拟电路连接。建立和回应资料流传送的连线请求﹐并验证传送期间的资料﹐同时对通讯进行侦错。
- 缓冲处理。如果程序送出的资料太小﹐协定将等到收集到一定大小的资料包之后才进行传送﹐然而协议允许“push”机制强行送出。
- 非结构化资料流。应用程序在建立连线之前﹐要先了解资料流动内容与格式﹐方能使用资料流服务。
- 全双工连线。允许双向性的资料传送﹐各自被视为互不相关的独立资料流。然而﹐它提供了返回资料流中携带传送控制资讯的机制。
TCP 协定在进行传输的时侯，必须依靠 IP 协议传送封包。相对于 TCP ， IP 协议属于不可靠协议﹐因为两个协议必需同时捆绑工作，因此只要其一能做到可靠传输就可以了。要详细的描述 TCP 如何提供可靠性传送是非常复杂的﹐但大部分可靠性协定都采用一定的确认机制来保证传送之可靠性。这种技术需要接收端以确认信息(Acknowledgement) 回应发送端﹐肯定资料无误的到达﹐同时双方保留传送的封包记录﹐以作下一笔资料的确认依据。此外﹐还利用定时器的机制﹐以在传送逾时后重新发送封包，以确保资料的完整性。我们可以从下图中看到确认机制的简单模式﹕
可靠性传送的确认机制
发送端在送出封包之后﹐会起始一个专门针对该封包的计时器﹐当下层网路延迟过久导致封包不能按预估时间获得接收端的确认信息﹐那麽发送端会认为该封包可能在传送过程中丢失﹐然后会重新发送该封包、并同时重设计时器﹔如果封包的确认信息在逾时前被接收到﹐则取消该封包的计时器﹐以进行下一封包的传送。
可靠性传送的计时器原理
计时器虽然解决了封包丢失的问题﹐但如果封包的抵达只是因为网路延迟的关系没有在预定时间完成﹐但却在发送端重发后抵达﹐那麽﹐接收端就有可能接收到重复的封包。为解决这个困绕﹐传送协议会为每一个封包分配一个序号﹐并要求接收端按封包序号传回确认信息。这样﹐当接收端收到封包的时候﹐则可以依据序号判断封包是否被重复传送，同时也能正确的重组资料顺序﹔而发送端也能根据确认封包的序号来判断封包是否被正确接收。
滑动视窗(Sliding Window)
从刚才介绍的可靠性传送知识作一个推断：假如每一个单一封包都需要等待前面的封包确认之后才进行传送的话﹐将会导致整个连线过程时间的增加﹐同时也会造成频宽的浪费。假如在低速的网路上面﹐或设备延迟﹐甚至还会造成网路处于空闲状态。有鉴于此﹐聪明的传送层协定设计者们引入了一个滑动视窗的概念。
我们可以将滑动视窗理解为多重发送和多重确认的技术。它允许发送端在接收到确认信息之前同时传送多个封包﹐因而能够更充份的利用网路频宽和加速资料传送速度。滑动视窗的操作可以想像为下图﹕
滑动视窗的工作原理
我们利用 Sliding Window 在收发两端各划分出一个缓冲范围(buffer)﹐定义了多大的资料量可被打包传送。在连线建立起来之初﹐两端都会将 window 的设定值还原到初始值﹐比方说﹕ 3 个封包。发送端一次过发送三个封包出去﹐如果接收端够顺利﹐也能一次处理接收下来的三个封包的话﹐就会向发送端确认全部三个封包，并告知接收端之 window 值为 3 。然后，发送端视窗则会往后移动三个封包﹐填补发送出去之封包的空缺。但如果接收端太忙﹐或是其它因素影响﹐暂时只能处理两个封包﹐那么﹐在视窗里面就剩下一个封包﹐然后就会告诉发送端 window 值为 2。这个时候﹐发送端就只送出两个封包﹐而视窗就会往后移动两个封包﹐填补发送出去的空缺。因此，视窗的大小是不固定的，这就是为什么我们会在视窗前面加上“滑动”字眼的原因了。(注意：这里使用封包数目作 window size 是不正确的，仅作例子参考而已。实际上的单位应是位元组，视不同的作业系统而各有不同，一般为 4096 bytes，但也有扩展至 16384 bytes 的。而且视窗的 size 是每个确认封包都不同的，端视当前的缓冲区状况，其机制比前述复杂许多。)
在启动滑动视窗之后﹐封包的传送看起来如下图﹕
启动滑动视窗后的传送
滑动视窗会记住哪些封包已经被确认﹐并且为每一个未被确认的封包保留各自的计时器。如果在逾时后还没得到该封包的确认﹐则重发该封包。发送端在移动视窗的时候﹐它会移过所有已确认的封包。在视窗中﹐编号最低的封包﹐往往是序列中的第一个未被确认的封包。
通讯端口(port)
大多数的作业系统都提供多工环境﹐允许多个应用程序同时执行﹐在系统术语里面﹐我们管每一个程式的起止为一个行程（进程）。每一个行程（进程）都是动态产生的﹐发送端无法预知接收端的某一个行程（进程）的实际状况如何。那么﹐当一个封包抵达目的地之后﹐接收如何将封包交给正确的行程（进程）处理呢﹖
在传送层协议里面﹐我们为程序产生的行程（进程）分配一个通讯端口﹐其值为一个正正数。当一个应用程序需要建立网路连线的时候﹐传送层协定就为该应用程式产生的行程（进程）建立一个端口。而事实上，所谓的网路连线，就是两个通讯端口之间的连线。关于网路通讯模式的建立有两种﹕
- 主动连线
- 被动连线
主动连线是当端口建立之后﹐行程透过该端口主动发出连线的要求﹔被动模式则是﹐当端口建立之后﹐行程在该端口等待连线的请求。在 client/server 的架构之下，连线的建立顺序通常是伺服器端先建立好被动连线﹐然后等待客户端的主动连线。
在技术上﹐行程使用哪一个端口并不重要﹐关键是能让对方知道端口是哪一个就行。我们可以把 IP 位址看成主机的门牌号码﹐而端口则是服务柜台。在多工的环境下﹐行程会在一个门牌上面开启多个柜台。您或许会问：由起始端主动发起之连线封包抵达之后﹐它究竟凭什麽来判断究竟哪个柜台才是正确的行程呢？在日常的生活中﹐大不了逐个柜台去问… 然而在网路系统上面﹐这个似乎有点不切实际。因为﹐每一个埠口的建立和关闭都是随机的﹐在不同的时段裡﹐所开启的埠口数目和号码都不尽相同。既然如此﹐等待连线那端何不先将接收行程所使用埠口号码告知起始端呢？但问题是：既然连线要由起始端主动建立才能连上等待端﹐在没有真正连上之前如何得知呢？不是鸡生蛋、蛋生鸡的问题吗？
有见及此﹐在网际网路的实作应用中﹐人们将一些常用的服务程式所使用埠口号码固定起来。例如﹕21 给 FTP 服务使用﹑23 给 TELNET 服务使用﹑25 给 SMTP 服务使用… 我们称这样的埠口为 Well-Known Port。在伺服器端﹐这些常用服务会先行建立好被动连线﹐打开所分配的埠口﹐以等待起始端的连线请求。那麽﹐起始端只要在封包填上目的端的埠口值﹐接收端就能将封包传给正确的服务了， 这也就是透过约定俗成的分配来建立连线。但事实上，您大可架设一个地下网站，故意使用其它非 Well-Known Port 来建立被动连线端口，这样，只有那些事先被告知端口值、且能修改主动连线设定的客户端才知门而入了。
除了使用 Well-Know Port 让起始端知道如何建立连线之外﹐传送协定也允许行程在连线建立之后﹐另行指定新的端口﹐告知发送端以建立新的连线。例如﹐ftp-data 连线在被动模式下的建立就是一个极佳例子(请参考其它文件以了解 ftp-data 的被动模式)。
无论如何，关于可靠传输的一个重要特性，我们不能忘记的一个特性就是﹕一个连线是双向的。在每一个传送层封包中﹐除了包含目的端的埠口值﹐同时也会附上接收端的来源埠口值。这样﹐目的端才能将回应资料送返发送端。不过﹐在大多数情况之下﹐起始端所使用的来源埠口都是随机产生的﹐只有在连线建立的时候才被分配﹐一旦连线结束﹐该埠口也将被释放。 即使随后马上再建立相同的连线，也难以确保所使用的埠口与上一次的一致。事实上，没有任何人、任何机器、任何程式(包括建立主动连线的程式) ，能够”预知”下一个起始连线会被分配在哪一个埠口之上。我们充其量，只能知到一般客户端所能建立的埠口值会是 1024 至 65535 之间。也只能知到如此而已，至于具体会是哪个埠口，就没办法预知了。请好好记住此一特性，日后在防火牆设定上可是非常有用哦。
Socket Pair
从前面的知识中，我们可以得知，所谓的一个网路连线，事实上就是两台机器之间的两个程序之间的连线。我们可以根据 IP 来区别主机、根据端口(port)来区别程序。在 TCP/IP 连线中，这是非常重要的概念，也就是所谓的 Socket 啦。
一个 Socket 就是由一个 IP 与一个 Port 来定义的，您可将之视为程序与 TCP/IP 连线之间的界面。准确来说﹐一个连线封包必须有四个元素，也就是所谓的 Socket Pair﹕
- 来源位址(Source Address)
- 来源端口(Source Port)
- 目的位址(Destination Address)
- 目的端口(Destination Port)
任何一个 TCP/IP 封包都肯定带有这对 Socket 的资讯，缺一不可。然而，来源 Socket 与目的 Socket 却是相对而言的，若离开了封包本身的具体连线方向，是没办法区分来源与目的的。因为连线是双向的缘故，若封包从客户端送往伺服器端，那么：客户端为来源、伺服器端为目的﹔若是从伺服器端送往客户端，则刚好相反。网际网路层依靠位址资讯将封包送抵目的地、处理完毕后将封包交由传送层处理、然后传送层则依据端口值、将封包交由相应的程式处理、至于程序如何处理封包信息﹐那就是应用层所要关心的问题… 这正是我们从 OSI 模型中学到的 “封装” 概念！
从编程的角度来说﹐程式不必理会底层的封包是如何传送的﹐只要程式能开启一个 socket ﹐并能对之进行读或写的动作﹐就可以与另一方的程序沟通了。至于 socket 的建立与维护﹐则交给传送层协议负责。
TCP 與 UDP
在 TCP/ IP 协定家族中﹐传送层主要有两个协定﹕TCP 与 UDP。究竟两者有何不同呢﹖简单而言﹐TCP 提供的是一个连线导向(Connection Oriented)的可靠传输﹐前面所介绍的传送层检测手续﹐都会在 TCP 中得到实现。相对而言﹐UDP 则是一个非连线型(Connectionless)的非可靠传输协议﹐它并不会运用确认机制来保证资料是否正确的被接收、不需要重传遗失的资料、资料的接收可不必按顺序进行、也不提供回传机制来控制资料流的速度。因此﹐ UDP 信息可能会在网路传送过程中丢失﹑重复﹑或不依顺序﹐而且抵达速度也可能比接收端的处理速度还快。对于某些讯息量较大、时效性大于可靠性的传输来说(比方说语音 / 影像)，UDP 的确是个不错的选择。
从 OSI 模型的封装原理中我们得知：一个网路封包就是经过层层加封的结果。其中，拿掉 header 的部份，就是 payroll 的空间、也就是上层协定封包及资料。然而，真正交由网路传送的 IP 封包是有一定的体积限制的( IP 封包的最大体积为 65536 bytes )。由于 UDP 不需要可靠传输，因此相较于 TCP 来说，一大堆必需占据封包表头的 over head 都可省略，从而换取更大的 payroll 空间。这样的结果，将令到单一的 IP 封包在作 UDP 连线时所携载的资料要比 TCP 连线多更多。这是靠牺牲可靠性而换取得来的，若连线需要在 UDP 上作可靠传输，那麽，其确认机制将从传输层退为应用层进行了、也就是程式本身要提供可靠传输机制。
下面﹐我们将分别以 TCP 和 UDP 的封包表头格式做更进一步的说明﹐以了解这两个传送层协议的异同之处。
TCP 封包表头格式
一个 TCP 封包的表头包括有如下栏位﹕
| Source Port (16) | Destination Port (16) | |||||||
| Sequence Number (32) | ||||||||
| Acknowledgment Number (32) | ||||||||
| Data Offset(4) |
Reserved (6) |
U G R |
A C K |
P S H |
R S T |
S Y N |
F |
Window (16) |
| Checksum (16) | Urgent Pointer (16) | |||||||
| Options (0 or more 32 bit words + padding) | ||||||||
| DATA … |
||||||||
一个 TCP 封包的表头包括有如下栏位：
- Source Port & Destination Port
- 这就是前述 Socket Pair 中的两个元素了。下面是一些 Well-Known Port 及其对应的服务名称﹐有兴趣的朋友可以在 Linux 的 /etc/services 这个档案找到它们﹕
ftp-data 20/tcp ftp 21/tcp telnet 23/tcp smtp 25/tcp mail www 80/tcp http # WorldWideWeb HTTP www 80/udp # HyperText Transfer Protocol pop-3 110/tcp # POP version 3 pop-3 110/udp
每一个 TCP 封包都包含有来源端和目的端的端口号码。在 Linux 的实作中﹐ Client 端通常都以大于 1024 的数值作来源端口号码。
- Sequence Number
- 封包序号。当资料要从一台主机传送去另一台主机的时候﹐发送端会为封包建立起一个起始序号﹐然后按照所传送的资料长度(位元组数值)﹐依次的递增上去﹔根据此一原理，我们可使用递增之后的值来作为下一个封包的序号。
- Acknowledge Number
- 回应序号。当接收端接收到 TCP 封包并通过检验确认之后﹐会依照发送序号、再加上资料长度产生一个回应序号﹐附在下一个回应封包送回给对方(无需额外的送出专门的确认封包)﹐这样接收端就知道刚才的封包已经被成功接收到了。假如基于网路状况或其它原因﹐当封包的计时器达到期限时﹐接收端还没接收到回应序号﹐就会认为该封包丢失了并加以重送。但如果刚好重发封包之后才接收到回应呢﹖这时候接收端就会根据序号来判断该封包是否被重复发送﹐如果是的话﹐很简单﹐将之丢弃不做任何处理就是了。
由此可见﹐Sequence 和 Acknowledge 是 TCP 传送中的重要检测手段﹐下面我们以一个模拟实例来看看这对号码是如何工作的。
发送端 步骤 接收端 起始第一个封包
seq=1234567 data_len=1001 2 收到第一个封包﹐将 100 bytes 的资料放进接收缓冲区内。 3 发出第一个确认封包
ack=1234667 data_len=0 ACK_bit=”on”收到第一个确认﹐ack 值与 seq+data_len 比对正确。从发送缓冲区内减除 100 bytes 的资料。 4 发送第二个封包
seq=1234667 data len=1505 6 收到第二封包﹐将 150 bytes 的资料放进接收缓冲区内 7 发出第二个确认封包﹐同时传送第一笔回传资料
seq=7654321 ack=1234817 data_len=50 ACK_bit=”on”收到第二个确认﹐ack 值与 seq+data_len 比对正确。从发送缓冲区内减除 150 bytes 的资料﹔同时将接收端送来的 50 bytes 资料放入接收缓冲区内。 8 发送第三个封包﹐且回应确认刚才接收的资料
seq=1234817 ack=7654371 data len=200 ACK_bit=”on”9 10 收到第三个封包以及第一个确认﹐ack 值与 seq+data_len 比对正确。从发送缓衝区内减除 50 bytes 的资料﹔同时将接收端送来的 200 bytes 资料放入接收缓衝区内。 …… … …… … 这样的设计除了能规范封包顺序以进行资料重组之外﹐还有另一个非常有用的功能： TCP 的确认会指出接收端下一个期望接收到的位元组序号。请好好记住这个工作原理，某些 state list 防火牆正是利用此一特性以低御 spoofing 及 hijack 。
- Data Offset (HLEN)
- 这是用来记录表头长度用的﹐和 IP 封包的 IHL 差不多﹕如果 options 没设定的话﹐其长度就是 20 bytes ﹐用十六进位表示就是 0x14 了﹐如果以 double word 长度来表示﹐则为 5 。
- Reserved
- 这是保留区间﹐暂时还没被使用。
- Contral Flag
- 控制旗标。一共有六个﹐它们分别是﹕
- Urgent data
- 当 URG 被设定为 1 的时候﹐就表示这是一个携有紧急资料的封包，接收端需优先处理。
- Acknowledge field significant
- 当 ACK 为 1 的时候﹐表示此封包的 Acknowledge Number 是有效的﹐也就是用来回应上一个封包。一般都会为 1。刚才介绍 Sequence 和 Acknowledge 的例子中﹐只有第一个封包没有设。
- Push function
- 如果 PSH 为 1 的时候﹐该封包连同传送缓冲区的其它封包应立即进行传送，而无需等待缓冲区满了才送。接收端必须尽快将此资料交给程式处理。
- Reset
- 如果 RST 为 1 的时候﹐连线会被马上结束，而无需等待终止确认手续。
- Synchronize sequence number
- 如果 SYN 为 1 时﹐表示要求双方进行同步处理﹐也就是要求建立连线。
- No more data fro sender (Finish)
- 如果封包的 FIN 为 1 的时候﹐就表示传送结束﹐然后双方发出结束回应﹐进而正式进入 TCP 传送的终止流程。
您或许有听过 TCP/IP 的 Three-Way Handshake ，事实上就是靠上面这几个旗标来标识封包的。TCP 协定之所以被认为是一个可靠的连线导向传输协定，正是因为它有一套严紧的连线建立与结束的机制来确保其可靠性。以 Three-Way HandShake 来说，它是 TCP 连线建立的前提：只有通过 handshake 才能进入真正的连线建立状态，否则不能建立连线。我们可从下图看出 Three-Way Handshake 的建立过程：
TCP 連線之建立過程
上图中的 Syn 与 Ack 就是 Contral Flag 的开关状态了，以此确定该封包在整个 TCP 连线所处的阶段。和通讯端口一样，请好好记住这些旗标，日后在防火牆设定上就派得上用途了。
- Window
- 这个就是我们在上前面介绍的“滑动视窗”了﹐在 TCP 封包表头的这个栏位﹐可得知对方目前的接收缓冲区大小( bytes )，从而决定下一个传送 Window 的大小。
- Checksum
- 当资料要传送出去的时候﹐发送端会对资料进行一个校验的动作﹐然后将校验值填在这里﹔当接收端收到封包之后﹐会再对资料进行校验﹐再比对校验值是否一致。若结果不一致则认为资料已损毁﹐并要求对方重送。
- Urgent Pointer
- 前面讲到 Control Flag 的时候我们提到一个 URG 的旗标﹐如果URG 被设定为 1 的时候﹐那这里就会指示出紧急资料所在位置。不过这种情形非常少见﹐例如当资料流量超出频宽的时候﹐系统要求网路主机暂缓发送资料﹐所有主机收到这样的信息﹐都需要优先处理。此时接收端会进入紧急状态，当紧急资料处理完毕后﹐接收端就会回复正常的接收状态。
- Option
- 这个选项比较少用。当那些需要同步动作的程式﹐如 Telnet ﹐要处理好终端的交互模式﹐就会使用到 option 来指定资料封包的大小﹐因为 telnet 使用的资料封包都很少﹐但又需要即时回应。Option 的长度要么是 0 ﹐要么就是 32bit 的整倍数﹐即使资料不足数﹐也要使用表头中没有的资料来填够。
UDP 封包表头格式
因为 UDP 是一种非可靠、非连线型的传输协定，因此无须像 TCP 那样提供额外的栏位来控制传输可靠性。比起 TCP 来说，UDP 的封包表头可精简多了：
| UDP Source Port (16) | UDP Destination Port (16) |
| Message Length (16) | UDP Checksum (16) |
| DATA … |
|
- Source Port & Destination Port
- 跟 TCP 的 Port 一样：就是 Socket Pair 中的两个元素，只是给那些透过 UDP 传送资料的程式使用而已。可在 Linux 的 /etc/services 这个档案找到各自 Well-Known Port。
- Message Length
- 整个 UDP 封包的长度，以位元组为单位( byte )，最小值为 8 。
- Checksum
- 封包及资料的校验值，跟 TCP 的 checksum 功能一样，用作资料完整性的检测依据。然而，关于 UDP 的 checksum 计算却有点复杂，因为其值必需连同一个所谓的 UDP 虚拟表头(UDP Pseudo Header) 一起计算的。虚拟表头如下：
Source IP Address (32) Destination IP Address (32) Zero (8) Protocol (8) UDP Length (16) 之所以称为虚拟，是因为其中的 Source IP Address 与 Destinatin IP Address 并不出现在 UDP 封包中，而是在 IP 封包中。但在进行校验的时侯，发送端与接收端则根据此 “虚拟” 的表头及资料进行。然而，此表头是不会出现在任何封包中的。
TCP 还是 UDP ?
如前所述，TCP 与 UDP 主要的差异在于是否提供可靠性传输。其真正目的是为上层应用程式提供不同的传输选择：
| 協定 | 優點 | 缺點 |
| TCP | 传送可靠，程式可省略可靠机制。 | 速度比较慢。 |
| UDP | 传输量大﹐迅速。 | 不可靠，程式或需自行提供可靠机制。 |
因此，不同的应用程式协定，会跟据自身的资料特性来决定其所需的传输服务。在整个 TCP/IP 协定家族中，其层阶关系如下图：
TCP/IP 协议家族
请再次运用所学的 OSI 模型原理，好好理解 TCP/IP 协定之层级关系，自然就有更明晰的观念了。若您懂得运用工具分析封包结构，将更有帮助。如下图，是我在 Windows 上用 netxray 抓到的一个封包，看您是否能解读出其中的栏位？
TCP 协议之 RFC 文件
RFC-793﹑RFC-1122﹑RFC-813﹑RFC-879﹑RFC-896
UDP 协议之 RFC 文件
RFC-768
习题﹕
- 请简单描述传输协定的功能。
- 请概括说明可靠性传输服务之要求有哪些。
- 请简单描述可靠性传输的确认机制。
- 请问何谓滑动视窗？请描述其必要性及工作原理。
- 请问埠口的作用是甚麽？何谓 Well-Know Port ？
- 请说明主动连线及被动连线的差异。
- 请问 Socket Pare 的元素有哪些，并说明双向连线中的 Socket 名称。
- 请简单说说 TCP 与 UDP 这两个传输协定之差异。
- 请画出 TCP 与 UDP 表头的每一个栏位，并逐一加以说明。
- 请以实例来分析 TCP 表头的 Sequence 与 Acknowledge 栏位的工作原理。
- 请简单描述 Three-Way Handshake 的过程，及 TCP 旗标的状态。
- 请说明 UDP 虚拟表头与 UDP Checksum 的关系。
- 请偿试以图表方式画出 TCP/IP 协定家族的层阶关系。
- 请以实作方式，运用封包分析工具来观察与解读 TCP 和 UDP 封包的结构。
风吹过，我来过！