通过端口号来区别不同的应用业务

传输层是TCP／IP协议中的重要的一层，在TCP／IP网络中，网络层解决通信子网的传输问题，传输层位于通信子网以外的主机中，解决端主机到端主机的传输问题以及向应用层提供主机到主机间的进程通信服务。

传输层在进行数据传输时，还需要完成数据报文的分段和组装。数据分段和分段数据组装过程是主机将应用层的数据报文交给传输层，传输层将该数据报文分解成若干数据段后，经封装交给网络层传输，到达对端后，解封数据分段组装成数据报文后交给应用层。

传输层在进行数据传输时，还要通过连接管理、差错控制，流量控制和拥塞控制等措施保证应用层交来的报文端到端的可靠传输。

在网络的应用业务中，会有不同的网络业务需求，有的网络业务需要较高的实时性，有的网络业务需要较高的可靠性。为了适应不同的通信子网和不同的应用要求，传输层提供了面向连接的传输控制协议TCP和用户数据报协议UDP。

TCP提供面向连接的服务，即在数据传输前必须进行建立连接，数据传输后要拆除连接。TCP通过连接管理、差错控制、流量控制提升传输可靠性，适用于可靠性相对较低的通信子网。但由于TCP协议的连接管理、差错控制、流量控制都需要一定的时间开销，所以TCP协议的实时性传输不太好，一般用于实时性要求不高，传输数据量较大的网络应用业务。

UDP协议是无连接的传输，传输时没有建立连接与拆除连接的过程，也不提供差错控制、流量控制机制，所以传输可靠性相对不高，适用于可靠性相对较高的通信子网。但由于没有连接管理和差错控制、流量控制的时间开销，所以UDP协议的实时性传输较好，一般用于实时性要求高，数据传输量较少的网络应用业务。

由于TCP、UDP协议分别对应两类不同性质的服务，上层的应用进程可以根据可靠性要求或传输实时性等要求决定是使用TCP协议还是UDP协议进行传输层数据传输。如HTTP、Telnet、FTP等网络应用业务一般使用TCP协议传输，而如DNS、DHCP、SNMP等应用业务一般使用UDP协议传输。

6.4.1　端口号的概念及功能

传输层实现端到端的传输控制，传输层的端到端传输，不仅是源主机到目的主机的端到端传输，而且还包括了源程序（进程）到目的程序（进程）的端到端通信。即传输层除了实现主机到主机的端到端通信外，还要通过传输层建立应用程序间的端到端连接，为主机应用程序提供进程通信服务。建立应用程序源端到目的端的连接就是为两个各应用传输实体建立一条端到端的逻辑通道，或者说是建立了进程间的通信逻辑通道。

网络中通过IP地址来区别不同的主机，通过IP地址将数据包送到了目的主机。但一个主机上可能同时运行了多个网络应用程序，传输层必须通过某种方法来区别不同应用程序产生的数据包。

传输层对不同的应用分配不同的端口号，通过端口号来区别不同应用程序产生的数据包。当一台主机同时运行多个网络应用时，每个应用都会产生自己的数据流（报文），传输层通过端口号来区分不同应用程序产生的数据流。

在发送方，源主机以源端口号指示出发送该数据报文的应用程序的端口号，以目的端口号指示出接收该TCP报文的应用程序的端口号，传输层以这样的方式实现了区别不同应用程序产生的数据流。

传输层端口的使用也实现了进程通信的复用和分用。进程通信的复用指在数据发送时，传输层将不同的应用产生的不同报文以不同的端口号表示，并统一交给网络层的IP通道进行传输，即多个业务的数据包都通过一个IP通道进行传输，实现了多个进程通信的复用传输。同样当不同的应用的响应数据包返回时，也由传输层根据不同的端口号分发到不同的应用程序，实现了多个进程通信的分用。

在OSI模型中，端口号相当于传输层的TSAP，是传输层与高层交互的服务访问点，是高层区别于不同应用程序（进程）的通信端口。应用进程通过系统调用与端口建立联系后，传输层传给该端口的数据都会被相应的应用进程所接收，即将报文提交给不同的应用进程。

TCP／IP设计了一套有效的端口分配和管理办法，端口号采用16比特进行表示，取值范围是0～4095。端口号按照使用情况被分为两大类：即保留端口和自由端口。保留端口由国际标准化组织统一分配并公之于众，保留端口的端口号从1～1023，其中：1～255的端口用于网络基本服务的公共的应用（Web、FTP、SMTP、DNS等），网络基本服务由TCP／IP统一分配了相应的端口号。如表6-2所示给出了常见的协议以及相应的端口号。

表6-2 常见的协议以及相应的端口号

255～1023　的端口是特定供应商应用程序的注册端口号。高于1023端口号是自由端口，未作规定，通信发生时，由系统分配使用。在Windows系统中，可以打开命令窗口，使用netstat命令查看到所有使用的端口号信息。

由于端口号就是应用程序的寻址号，所以主机在发送应用程序的数据之前，都必须确认端口号，存在静态分配与动态分配两种分配端口号的方法。

（1）静态分配的端口号

对于以上HTTP、FTP、DNS、DHCP等特定的应用，它们的端口号是事先统一分配的，是不能改变的，这些端口号属于静态分配。

（2）动态分配（绑定）的端口号

如果用户应用不是以上特定的应用，没有特定分配的端口号，则系统将在高于1023的取值范围为该用户的应用分配一个当前没有用过的端口号。

（3）端口号放在TCP、UDP报文的报头中

端口号是应用进程的通信地址，传输层在进行数据报文传输时，将端口号填入报头中的端口号字段随报文传输。端口号分源端口号和目的端口号。源端口号指示出发送该数据报文应用程序的端口号，目的端口号指示出接收该TCP报文的应用程序的端口号。

由于TCP、UDP是完全独立的两个软件模块，它们的端口号可以互相独立使用。即同一端口号既可以在TCP协议中使用，也可以在UDP协议中使用。

（4）端口使用的例子

例1：在如图6-19中，主机A要Telnet到主机B，Telnet的端口号为23，主机在发起连接时，主机A向TCP请求一个端口号，TCP分配给的端口号为1088，主机A将此端口号作为源端口号，将23作为目标端口号，封装成传输层报文后，由主机A向主机B发送。该报文达到主机B后，主机B看到主机A发过来的目的端口号为23，知道这是一个Telnet应用进程，将它提交给上层的Telnet应用，为该次通信建立了Telnet会话。

图6-19 端口使用（例1）

例2：主机A有两个用户，同时向主机B提出Telnet请求，此时A主机的TCP在第一个用户发出请求时，已经分配了一个端口号1088，在第二个用户向TCP发出请求时，A主机的TCP将为其分配另外一个端口号1089给第二个用户，主机A通过不同的端口分配实现对不同用户的鉴别。

（5）套接字的概念及作用

在TCP、IP网络中，当出现两台以上的主机都有用户在完成同样的应用时，他们可能使用了相同的端口号去访问相同的应用程序。此时单用端口号已经不能区别是哪台主机的应用进程，在这种情况下，需要用套接字来解决。套接字将端口号和IP地址结合起来实现相同应用、相同端口号访问的鉴别。

图6-20 套接字的使用

例3：在图6-20中，主机A和主机B都有用户在收发电子邮件，主机A为主机A用户分配的端口号是1088，而主机B为用户分配的端口号也是1088，此时对于邮件服务器，此时单用端口号已经不能区别是哪台主机的应用进程。而采用套接字后，主机A的套接字为172.16.1.29：1088；主机B的套接字为128.193.80.99：1088，显然，虽然主机A和主机B的源端口号完全相同，但由于不同主机具有不同的IP地址，所以可以清晰地区分是不同主机发出的邮件服务请求。

6.4.2　TCP协议

TCP协议是面向连接的传输协议，具有传输可靠性高的优点。面向连接的传输方式在数据传输前需要建立连接，数据传输结束后需要拆除连接。TCP的建立连接是在应用进程间建立传输连接，它是在两个传输用户之间建立起一种逻辑联系，使得双方都确认对方存在，确认传输连接点，并为本次传输协商参数，分配资源，为本次传输建立起一条逻辑通道，TCP报文就在这个逻辑通道中进行传输。进程逻辑通道的建立示意如图6-21所示。当主机端有多个进程需要通信时，他们需要建立多个逻辑通道，即需要建立多个TCP连接。

图6-21 进程逻辑通道的建立示意

在传输层，TCP协议传输的报文通过应答确认和超时重传等差错控制措施保证源端数据成功地传递到目的端，通过流量控制和拥塞控制机制等措施保证发送流量不超过处理能力和通信子网的吞吐能力，并为传输报文设置QoS等，通过这些措施来进一步提高传输可靠性。

（1）TCP报文格式

传输层收到应用层提交的数据后，由TCP协议将数据进行分段，然后将数据段封装成TCP报文进行传输。TCP报文由报文首部和数据部分构成，TCP报文的数据就是分段后的数据块，在数据块前面加上TCP头部就形成了TCP数据报文（如图6-22所示）。

TCP是建立在IP之上的，每个TCP报文是封装在IP数据包的数据区中进行传输的，TCP报文及IP包数据封装关系如图6-22所示，封装了TCP数据报文的IP包协议类型字段为6。

TCP报文头部由定长部分和变长部分构成，定长部分长度为20字节，变长部分是选项，长度在0～40字节之间，TCP段格式如图6-23所示。报文格式中各个部分和含义和作用如下：

①端口号：最前面是源端口号和目的端口号，各使用16比特。源端口号指示出发送该数据报文应用程序的端口号，目的端口号指示出接收该TCP报文的应用程序的端口号。

图6-23 TCP段格式

②发送序号：发送序号为32比特，指示出当前发送报文中的第一个数据字节的序号。通过序号指示出目前的TCP段的属于第几个TCP段，作为接收方重新组装的依据。

③确认序号：确认序号是期望从发送方接收的下一个报文的序号，同时应答了前一个报文已经正确接收。TCP协议采用了捎带应答的方式，传输双方在给对方发送数据报文时，通过确认序号，将自己收到的报文的应答带回。如确认序号为X＋1，则表示期望从发送方接收序号为X＋1的报文，同时报告发来的序号为X的报文已经正确接收。

④头长度字段：由于报头中有选项部分，选项部分长度不固定，必须通过头长度字段指示出当前报头长度，从而在数据段到来时，能够识别，接收处理。报头在无选项时为20字节，有选项时可达60字节。

⑤保留字段：保留字段目前没用，置位0。

⑥编码字段：编码字段用于TCP的流量控制、连接管理（建立、拆除）和数据的传输方式设置等。这6位从左到右分别为：

紧急指针有效位URG，URG＝1表示该报文要尽快传输，而不必按原排队次序发送，即使是发送窗口为零也要将该数据报文进行传输；

应答确认有效位ACK，ACK位是与确认序号配合使用的字段，当ACK＝1表示该TCP段的确认序号有效。

推送数据有效位PSH，当一收到PSH＝1的TCP段时，就立即将其提交给应用程序，而不必是放在缓冲区中排队。

连接复位（用于连接故障后的恢复）RST，当RST＝1，说明已经发生严重错误，必须释放连接。

同步标志位SYN，当SYN＝1，表示请求建立连接。同步标志位标识该包为建立连接的请求包。

终止连接标志位FIN，FIN表示数据发送完毕，终止连接标志位标识该包为拆除连接指示包。

⑦窗口：窗口大小为16比特，窗口用于流量控制，在建立连接阶段，根据自己缓存空间的大小确定自己的接收窗口大小，同时使用16比特的窗口字段告诉它期望的发送窗口的大小。

⑧校验和：校验和的长度为16比特，校验和的范围包括段首部、数据，用来对头部信息和数据信息进行差错校验。在TCP／IP协议栈中，TCP校验是数据段差错校验的唯一手段。

⑨紧急指针：紧急指针为16比特，只有在编码段的URG＝1时才使用紧急指针字段。URG＝1指出该报文是紧急报文，要尽快传输，此时将要发送的数据的最后一个字节填入紧急指针字段中，表明该字节之前的数据是紧急数据。

⑩可选项：在默认头部中没有此项，当使用此项时，用于设定TCP报文能够接受的最大数据长度MSS（Maximum Segment Size）。当TCP报文的MSS设置得太大时，在IP层可能将被分解为更多的数据分组，这将增大传输开销。在建立连接阶段，收发双方都可将自己的MSS写入选项字段，在数据传输阶段，MSS取双方的较小值。在没有设置MSS时，TCP报文数据段的数据长度默认为536字节，因此，TCP／IP网络上的主机都能接受报文长度为556字节的TCP报文（加上20字节的报头）。

数据字段：填装上层需要传输的数据，数据段必须是16比特的整数倍。

（2）TCP的连接管理——三次握手机制

TCP采用面向连接的传输方式，面向连接的传输方式在数据传输前要有建立连接的过程，传输完毕要有拆除的过程。

建立连接的过程是确认对方的存在，协商（设置）一些参数（MSS值、最大窗口、服务质量等），并对传输中会使用的资源进行分配（缓存大小、连接表项空间等），使传输实体双方准备好传送和接收数据。由于通信子网的多样性和复杂性，为了防止请求连接数据包通过通信子网发生丢失而引起源主机端无限制的等待，TCP在发送方在发出请求连接后就启动一个计时器，发送方在计时器到达设定时间仍然没有得到接收方的响应时，会再次发出请求连接。

一般来说，建立传输连接只需一个请求、一个响应就可以了，但是由于经过通信子网传输时，请求连接的数据包可能会发生丢失，丢失后需要重新建立连接。如果发生的情况是建立连接的请求包没有发生丢失，仅仅是传输延迟导致建立连接的请求包较迟到达，在这种情况下，系统就会发生重复连接。系统发生重复连接时，将会浪费系统资源，还会产生不必要的时间开销，所以TCP协议需要解决重复连接问题。

解决重复连接的办法是采用三次握手机制实现连接管理。该办法在源主机收到目的主机的确认信息后，还要向目的主机发出一个确认响应包，让目的主机确认源主机已经收到确认响应包。三次握手的具体过程如图6-24所示：

①A主机发出请求连接数据包，在数据包中的发送序号字段中填入主机当前还没有使用的最小序号x，此时发送SYNseq＝x；

②B主机收到该请求连接数据包，需要应答发送方，此时，接收方同样在数据包中的发送序号中填入当前没有使用的最小序号y，此时SYNseq＝y，同时在应答确认序号中填入x＋1，即ACKseq＝x＋1，该应答报文表示发来的序号为x的请求连接报文已经收到，现期望接收SYNseq＝x＋1的报文。

③A主机端收到该应答报文时，再发出一个收到应答报文的确认报文给B主机，此时，源主机的填入的应答确认序号为ACKseq＝y＋1，该确认应答报文表示B主机发来的序号为y的应答报文已经收到。

图6-24 三次握手的具体过程

三次握手保证了源A机和B主机都知道对方已收到自己发出的报文，确保对方已经跟自己建立了连接，双方都已经做好了数据传输的准备，本次传输是可靠的传输。

采用三次握手方式当由于延迟产生的重复连接报文到来时，由于目的主机已经明确收到来自源主机的应答，目的主机可以知道这是一个不正常的连接，不会对该请求再次建立连接，避免了系统资源浪费。

（3）TCP的数据传输

建立连接完成以后，双方就进入数据传输阶段，在数据传输阶段，由于TCP建立的是全双工的逻辑通道，发送方和接收方都可以同时进行数据传输。在发送的数据包中，将当前发送的数据的第一个字节的序号填入发送序号字段，对方收到后，在给源端发送数据的数据包中的确认序号字段捎带上已经正确接收到源端发来的数据包的应答信息。

如图6-25是一个数据传输时的例子：设A主机要向B主机发送1800字节的数据，B主机要向A主机发送1500字节的数据。设本例中主机A正好取了8001为第一个字节的编号，由于数据长度为1800，所以字节编号为8001～9801，同理，主机B的字节编号假设为16001～17500。本例中，A主机发往B主机的数据被分为两段进行发送，第一段数据为8001～9000，第二段数据为9001～9800。此种情况下，A主机发送第一段数据时，填入的发送序号为8001，A主机发送第二段数据时，填入的发送序号为9001。B主机发往A主机的数据正好以1500字节为一个本文段，所以B主机发送给A主机的数据时，正好放在一个报文段中，改报文段的序号为16001。B主机发送给A主机报文段时，填入的发送序号为16001。

图6-25 TCP的数据传输

TCP采用连续发送方式进行数据发送，当发送方按照发送窗口规定的大小发送完若干个数据包时，就不能再发送，而是等待接收方的应答到来。而接收方的应答是采用捎带的方式进行应答，即接收方利用给对方发送数据包的时候，将应答信息装在向对方发送的数据包中捎带到对方。这种捎带应答的方式可以减少网络中数据包流量，可以有效地利用网络带宽，提高数据传输速度。

在TCP协议中，数据包的确认并不是对每一个包都确认，只对最后收到的数据包进行确认，以应答包中的确认序号表示，该应到包表示该确认序号以前的各个数据包都已经正确接收。在以上例子中，假设发送窗口为2，所以B主机在收到2个报文段后，就进行应答，应答填写的确认序号为9801，说明8001～9000报文段和9001～9800报文段都已正确收到。

（4）拆除连接

数据传输完毕需要拆除连接，以收回本次传输占用的各种资源。拆除连接的过程如图6-26所示。

图6-26 TCP的拆除连接

A主机的应用程序通知TCP数据传输已经结束时，A主机的TCP向B主机发送一个拆除连接的报文，通知对方传输结束，B主机收到这个报文后，先发一个确认报文给A主机，表示已经收到拆除连接请求，同时，通知B主机相应程序，源端要求结束传输。B主机的应用程序收到该通知后，确认自己可以结束传输，通过TCP发出一个结束传输的报文给A主机，A主机收到该报文时，再发出一个确认应答报文给B主机，确认传输结束，至此，整个拆除连接的过程结束。

（5）TCP的差错控制

差错控制是TCP保证可靠性的手段之一，TCP的差错控制包括检错和纠错。TCP处理的差错有数据出错，以及重复、失序和丢失。

TCP采用超时重传的方式实现差错控制。如果在传输过程中，丢失了某个序号的数据包，导致发送方在给定的时间内没有收到该包相应的确认序号，那么发送方视该数据包为丢失，发送方将重新发送该数据包。在发送方，已经发送出去的数据会保留在发送方缓冲区中，直到发送方收到确认才会清除缓冲区中的这个数据。

数据出错通过TCP段中的校验和字段进行差错检测，通过校验检测出差错发生后，丢弃出错的数据包，而且不给予应答确认，通过定时器超时后，重发该数据包使错误得到恢复。

同样数据包的丢失错误TCP也是通过超时重传来进行恢复。数据包发生丢失时将导致达到定时时间还没有应答确认回来，此时采用超时重传来进行数据包发送恢复。如果在发送方启动超时重发后，接收方又收到的该数据包，此时也没关系，重复发送的数据包将会被接收方鉴别出来，并被丢弃。

数据报文失序指数据包没有按顺序达到。由于网络层的IP协议是无连接的数据报协议，不能保证数据包按顺序到达。TCP对提前到达的数据包暂不确认，直到前面的数据包到达后再一起确认。对于由于失序导致超时后仍然未收到确认应答，将重复发送该数据包。这种处理可能会带来收到重复的数据包，只要丢弃该重复的数据包即可。

影响超时重传的关键是重传定时器定时时间的大小，由于因特网中传输延迟变化范围很大，因此从发出数据到收到确认所需额度往返时间也是动态调整的。TCP通过在建立连接时获得连接的往返时间，对重传时间进行设定。TCP通过校验和字段来进行差错校验，校验的范围包括对头部信息和数据信息进行差错校验。在TCP／IP协议中，TCP校验是数据段差错校验的唯一手段。校验和的计算方法如下：

在计算校验和时需要使用12个字节的伪首部，这12个字节分别为4个字节为源IP地址，4个字节的目的IP地址；另外1个字节的全0字段，1个字节的版本号字段（IPv4网填写4，IPv6网填写6），2个字节的TCP报文段长度字段。数据发送时，发送端先将校验和字段的16位置为全0，再将伪首部和TCP报文段（包括头部和数据）看成是若干个16比特的字串接起来，如果TCP报文段不是字节的偶数，则要填入一个全为0的字节，然后按二进制反码计算这些16比特串的和，最后将算出的这个和（也是16比特）的二进制反码填入校验和字段，并发送该TCP报文。在接收方，将收到的TCP报文连同伪首部一起，按照二进制反码求这些16比特串的和，若计算结果为全1，则传输没有发生差错，否则为发生差错。

将伪首部一起加入校验的方式使得该检错既检查了TCP报文的头部信息和数据部分，同时还检查了IP数据包的源IP地址和目的IP地址是否出错。

（6）TCP的流量控制、拥塞控制

流量控制是针对由于不能及时处理数据而引发的控制机制。拥塞控制是针对由于通信子网中流量过多，导致通信子网中的路由器超载引起严重的延迟现象的控制。TCP的流量控制通过滑动窗口机制限制发送的数据段的数量，达到流量控制和拥塞控制的目的。发送窗口机制的发送窗口大小决定了在收到确认信息之前一次可以发送的数据段的最大数目。如发送窗口为5，则连续发送5个数据段后，就必须等待对方的应答，在接收到确认信息后才可以再发送下面的数据段。

TCP的流量控制采用的是逐渐加大发送窗口的办法进行窗口大小控制。在建立连接阶段，设初始窗口为1，当收到这个段的应答后，将窗口增加至2，再次收到应答后，窗口增加至4，以此类推。当窗口达到门限值，（拥塞发生时的窗口值的一半），进入拥塞避免阶段，此时每收到一个应答，窗口只增加1，减缓窗口的增加速度，但窗口仍然在增长，最终导致拥塞。拥塞将导致发送方定时器超时，进入拥塞解决阶段。在组织重传的同时，将门限值调整为拥塞窗口的一半。并将发送窗口恢复成1，然后进入新一轮循环。

可以看出，TCP协议通过发送窗口来实现流量控制，当不能及时处理数据时通过减小窗口，减少发出的数据，缓减的压力。TCP协议通过门限值设定来处理拥塞问题，当网络中出现由于流量拥挤发生的数据段丢失时，通过调整门限值，系统自动将发送窗口减小一半。

6.4.3　用户数据报协议

用户数据报协议UDP（User Datagram Protocol）属于无连接传输方式，相对可靠性不高，一般用于可靠性较好的通信子网的数据传输。由于UDP是无连接的传输服务，协议简单，没有建立连接、拆除连接阶段，仅提供简单的差错控制，不提供流量控制，从而减小了传输时间开销，传输效率高，一般用于实时性要求较高的业务，或者用于一次传输得数据量较少的业务情况。UDP将应用层的数据封装成数据报进行传输，UDP发送出去的每一个数据报都是独立的，不同的数据报之间是没有联系的，UDP不需要编号，对收到的数据报也不发送确认，发起数据传输时也不需要建立连接、数据发送完毕也没有拆除连接的过程，相对TCP协议，UDP协议简化了很多。

UDP收到应用层的数据后，在数据前封装一个UDP报头形成UPD报文。应用层的用户数据与UDP报文及IP包数据封装关系如图6-27所示。

图6-27 应用层的用户数据与UDP报文及IP包数据封装关系

由于UDP不是将一个大的报文分割成多个相互关联的数据报文后再进行传输，而是直接将应用层的数据封装后进行传输，所以UDP报文中没有数据顺序的序号等字段，在接收方也不存在排序组装等问题，UDP一般用于数据量较少的报文传输。

整个UDP数据报是封装在IP数据包的数据区中进行传输的，封装了UDP数据报文的IP包协议类型字段为17，UDP报文格式如图6-28所示。

图6-28 UDP报文格式

可以看出UPD的报文格式也比较简单，仅有源端口、目的端口，报文长度、校验和以及数据字段。各个字段意义如下：

①源端口：源端口字段为16位，表示发送方UDP端口号；

②目的端口：目的端口字段为16位，表示UDP端口号；

③报文长度：报文长度字段为16位，报文长度用于指示整个UDP数据报的总长度，以字节为单位，最小值为8（即无数据段时）；

④校验和：检验和字段为16比特，完成头部信息的校验。

与TCP报文格式比较，它们头部的第一个字段都是端口号，后面部分UDP的很简单，只有报文长度和对头部信息进行校验的校验和，数据部分就是高层应用程序交来的数据。

UDP协议由于简单，协议时间开销小，也带来实现简单、占用资源少、传输延迟小，容易运行在处理能力低的节点上，适用于通信网络质量高，传输业务实时性要求高的业务，如RIP、DNS、DHCP、SNMP等。

6.4.4　TCP与UDP的对比

表6-3所示为TCP与UDP传输协议的特点及使用情况的对比。

表6-3 TCP与UDP的特点及使用情况对比