精华内容
下载资源
问答
  • 传输层协议

    千次阅读 2018-10-20 21:53:56
    1 传输层协议 网络层只把分组发送到目的主机,但是真正通信的并不是主机而是主机中的进程。传输层提供了进程间的逻辑通信,传输层向高层用户屏蔽了下面网络层的核心细节,使应用程序看起来像是在两个传输层实体之间...

    传输层

    1 传输层协议

    网络层只把分组发送到目的主机,但是真正通信的并不是主机而是主机中的进程。传输层提供了进程间的逻辑通信,传输层向高层用户屏蔽了下面网络层的核心细节,使应用程序看起来像是在两个传输层实体之间有一条端到端的逻辑通信信道。

    传输层主要协议:UDP、TCP

    UDP 和 TCP 的特点

    用户数据报协议 UDP(User Datagram Protocol)是无连接的,尽最大可能交付,没有拥塞控制,面向报文(对于应用程序传下来的报文不合并也不拆分,只是添加 UDP 首部),支持一对一、一对多、多对一和多对多的交互通信。
    
    传输控制协议 TCP(Transmission Control Protocol)是面向连接的,提供可靠交付,有流量控制,拥塞控制,提供全双工通信,面向字节流(把应用层传下来的报文看成字节流,把字节流组织成大小不等的数据块),每一条 TCP 连接只能是点对点的(一对一)。
    

    2 UDP 首部格式

    首部字段只有 8 个字节,包括源端口、目的端口、长度、检验和。12 字节的伪首部是为了计算检验和临时添加的。

    3 TCP 首部格式

    TCP报文段首部的前20个字节是固定的,后面有4N字节是根据需要而增加的选项。因此TCP报文段的最小长度为20个字节。

    首部固定部分的各字段的意义如下:

    1. 源端口和目的端口:加上IP首部的源IP地址和目的IP地址,确定唯一的一个TCP连接。另外通过目的端口来决定TCP将数据报交付于那个应用程序,从而实现TCP的分用功能。

    2. 序号:占4个字节,序号的范围为[0,4284967296]。由于TCP是面向字节流的,在一个TCP连接中传送的字节流中的每一个字节都按顺序编号,首部中的序号字段则是指本报文段所发送的数据的第一个字节的序号。另外,序号是循环使用的,当序号增加到最大值时,下一个序号就又回到了0。

    3. 确认号:当ACK标志位为1时有效,表示期望收到的下一个报文段的第一个数据字节的序号。确认号为N,则表明到序号N-1为止的所有数据字节都已经被正确地接收到了。

    4. 头部长度:TCP报文段的头部长度,它指出TCP报文段的数据部分的起始位置与TCP报文段的起始位置的距离。头部长度占4个字节,但它的单位是32位字,即以4字节为计算单位,因此头部长度的最大值为15*4=60个字节,这就意味着选项的长度不超过40个字节。

    5. 保留位:必须为0.

    6. 下面的六个控制位说明报文段的性质

    1)URG:与首部中的紧急指针字段配合使用。URG为1时,表明紧急指针字段有效,发送应用进程告诉发送方的TCP有紧急数据要传送,于是发送方TCP就把紧急数据插入到本报文段数据的最前面,而其后面仍是普通数据。

    2)ACK:仅当ACK=1时确认号字段才有效,当ACK=0时,确认号无效。TCP规定,在连接建立后所有的传送报文段都必须把ACK置1。

    3)PSH:如果发送的报文段中PSH为1,则接收方接受到该报文段后,直接将其交付给应用进程,而不再等待整个缓存都填满后再向上交付。

    4)RST:复位标志,RST=1时,表明TCP连接中出现严重差错,必须释放连接,然后重新建立运输连接。

    5)SYN:同步序号,用来发起一个连接。当SYN=1而ACK=0时,表明这是一个连接请求报文段,若对方同意建立连接,则应在响应的报文段中使SYN=1和ACK=1。

    6)FIN:用来释放一个连接。当FIN=1时,表明此报文段的发送方的数据已发送完毕,并要求释放连接。

    1. 窗口:接收方让发送方下次发送报文段时设置的发送窗口的大小。

    2. 校验和:校验的字段范围包括首部和数据这两部分。

    3. 紧急指针:紧急指针当URG=1时才有效,它指出本报文段中的紧急数据的字节数。值得注意的是,即使窗口为0时,也可发送紧急数据。

    4. 选项与填充:选项应该为4字节的整数倍,否则用0填充。最常见的可选字段是最长报文大小MSS(Maximum Segment Size),每个连接方通常都在通信的第一个报文段中指明这个选项。它指明本端所能接收的最大长度的报文段。该选项如果不设置,默认为536(20+20+536=576字节的IP数据报),其中ip首部和tcp首部各20个字节,而internet 上标准的MTU (最小)为576B。

    3. TCP 的三次握手

    假设 A 为客户端,B 为服务器端。

    首先 B 处于 LISTEN(监听)状态,等待客户的连接请求。

    A 向 B 发送连接请求报文,SYN=1,ACK=0,选择一个初始的序号 x。

    B 收到连接请求报文,如果同意建立连接,则向 A 发送连接确认报文,SYN=1,ACK=1,确认号为 x+1,同时也选择一个初始的序号 y。

    A 收到 B 的连接确认报文后,还要向 B 发出确认,确认号为 y+1,序号为 x+1。

    B 收到 A 的确认后,连接建立。

    三次握手的原因

    第三次握手是为了防止失效的连接请求到达服务器,让服务器错误打开连接。

    客户端发送的连接请求如果在网络中滞留,那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后,就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器,如果不进行三次握手,那么服务器就会打开两个连接。如果有第三次握手,客户端会忽略服务器之后发送的对滞留连接请求的连接确认,不进行第三次握手,因此就不会再次打开连接。

    4. TCP 的四次挥手

    以下描述不讨论序号和确认号,因为序号和确认号的规则比较简单。并且不讨论 ACK,因为 ACK 在连接建立之后都为 1。

    A 发送连接释放报文,FIN=1。

    B 收到之后发出确认,此时 TCP 属于半关闭状态,B 能向 A 发送数据但是 A 不能向 B 发送数据。

    当 B 不再需要连接时,发送连接释放报文,FIN=1。

    A 收到后发出确认,进入 TIME-WAIT 状态,等待 2 MSL(最大报文存活时间)后释放连接。

    B 收到 A 的确认后释放连接。


    四次挥手的原因

    客户端发送了 FIN 连接释放报文之后,服务器收到了这个报文,就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据,传送完毕之后,服务器会发送 FIN 连接释放报文。

    TIME_WAIT

    客户端接收到服务器端的 FIN 报文后进入此状态,此时并不是直接进入 CLOSED 状态,还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由:

    确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文,那么就会重新发送连接释放请求报文,A 等待一段时间就是为了处理这种情况的发生。

    等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失,使得下一个新的连接不会出现旧的连接请求报文。

    5 客户端、服务端状态变更

    客户端状态变更


    服务端状态变更

    6. TCP 的性质

    6.1 TCP 可靠传输

    TCP 使用超时重传来实现可靠传输:如果一个已经发送的报文段在超时时间内没有收到确认,那么就重传这个报文段。

    一个报文段从发送再到接收到确认所经过的时间称为往返时间 RTT,加权平均往返时间 RTTs 计算如下:

    其中 RTTd 为偏差。

    6.2 交互数据流和成块数据流

    交互数据类型,如:Telnet,这类协议一般只做小流量的数据交换,比如每按下一个键,要回显一些字符。

    成块数据类型,如:FTP,这类协议需要传输的数据比较多,一般传输的数据量比较大。

    6.2.1 交互数据流

    针对交互性要求比较高的应用,每发送一个字节到服务端,并回显到客户端的过程如下:

    1. 客户端产生一个41bit长的报文(20字节的IP首部,20字节的TCP首部,1字节的数据),发送到服务端;

    2. 服务端发送过来一个40bit的确认报文;

    3. 服务端发送回显的字符,报文长为41bit;

    4. 客户端发送确认报文,报文长为40bit。

    如果在局域网中,通常不会有什么麻烦,因为局域网一般不会出现拥塞,但在广域网中,这些小分组则会增加网络拥塞出现的可能。为了提高这类数据的发送效率和降低网络负担,TCP采用了两种策略:捎带ACKNagle算法

    捎带 ACK :
       捎带ACK的意思是,当接收端接收到TCP报文段后,并不立即发送ACK报文,而是等上一段时间,如果这段时间里该主机有数据要发送到远程主机,就将该数据捎带上ACK一起发送过去,很明显,这样可以减少传输开销。为了防止产生超时重传,绝大多数情况下,这个等待时间为200ms,超过了200ms,如果没有数据要一起发送,就直接发送ACK报文。

    捎带ACK的策略一般也只有在交互性比较高的应用中才会使用,对于成块数据流,一般大多数应用程序不会同时在两个方向上发送数据。

    Nagle算法
      该算法的重点是要求在TCP连接上组多只能有一个未被确认的数据报在传输。算法的大致思路如下:应用程序把要发送的数据逐个字节地从到TCP的发送缓存,发送方把前面的一部分数据先发送出去,并把后面到达的字节继续缓存起来,当发送方收到前面字节的确认后,再把发送缓冲中的所有数据组装成一个报文段发送出去,同时继续对随后到来的数据进行缓存。只有收到前一个报文段的确认后才能继续发送下一个报文段。另外,Nagle算法还规定,当发送缓存中的数据已达到发送窗口大小的一半或已达到报文段的MSS值时,就立即发送一个报文段。
      当数据到达较快而网络速率较慢时,用这种方法可明显地减少所用的网络带宽。很明显,该算法也是专门为交互性高的应用而设计的,对于成块数据流,如果每收到一次确认才能发送下一个报文段,那么传输速率就会很低。

    6.2.2 成块数据流

    对于一些数据吞吐量要求较高的应用,总是希望每次发送尽可能多的数据到主机,对于这类应用,TCP使用滑动窗口协议,该协议允许发送方在停止发送前和等待确认前可以连续发送多个分组,因此可以加速数据的传输。

    滑动窗口

    滑动窗口的滑动是以字节为单位的,发送方A和接收方B在TCP三次握手的前两次握手时协商好了发送窗口和接受窗口的大小,发送方A根据B发送来的确认连接报文中标明的窗口的大小,来确定收到确认前的最大发送数据量,如果A接收到的B发来的确认报文中标明的窗口大小为0,则停止发送数据,直到收到不为0的确认报文,再继续发送。发送窗口表示在没有收到B的确认的情况下,A可以连续把窗口内的数据都发送出去,凡是已发送过的数据,在没有收到确认前都要暂时保留,以便超时重传时使用。

    需要注意的一点是:使用TCP滑动窗口协议时,接收方不必确认每一个收到的分组,在TCP中,ACK确认是累积的,可以在接收到几个序号连续的报文段后只发送一个ACK确认报文,但累积等待的时间最长不能超过0.5秒,以防止发送端超时重传。

    另外,要注意滑动窗口的三种变化:

    1. 窗口合拢。窗口左边沿向右边沿靠近,这种情况发生在数据被发送后收到确认时;

    2. 窗口张开。窗口右边沿向右移动,说明允许发送更多的数据,这种情况发生在另一端的接收进程从TCP接收缓存中读取了已经确认的数据时;

    3. 窗口收缩。窗口右边沿向左移动,一般很少发生,RFC也强烈不建议这么做,因为很可能会产生一些错误,比如一些数据已经发送出去了,又要收缩窗口,不让发送这些数据。

    另外,窗口的左边沿是肯定不可能左移的,如果接收到一个指示窗口左边沿向左移动的ACK,则它被认为是一个重复ACK,并被丢弃。

    总结以下几点:

    1. 发送方不必发送一个全窗口大小的数据,一次发送一部分即可。

    2. 窗口的大小可以减小,但是窗口的右边沿却不能向左移动。

    3. 接收方在发送一个ACK前不必等待窗口被填满。

    4. 窗口的大小是相对于确认序号的,收到确认后的窗口的左边沿从确认序号开始。

    发送接收缓冲区

    1. 缓冲空间和序号空间都是有限的,并且都是循环使用的。

    2. 窗口大小一定不大于收发缓冲区的大小

    3. 发送缓冲区用来暂存发送方准备发送的TCP报文段和已发送但尚未收到确认的数据。

    4. 接收缓冲区用来暂按序到达但尚未被上层应用程序读取的数据合未按序到达的数据。

    6.3 四大定时器

    对于每个TCP连接,TCP一般要管理4个不同的定时器:重传定时器坚持定时器保活定时器2MSL定时器

    6.3.1 重传定时器

    很明显重传定时器是用来计算TCP报文段的超时重传时间的(至于超时重传时间的确定,这里涉及到一大堆的算法,书上有说,我这里不细谈了)。每发送一个报文段就会启动重传定时器,如果在定时器时间到后还没收到对该报文段的确认,就重传该报文段,并将重传定时器复位,重新计算;如果在规定时间内收到了对该报文段的确认,则撤销该报文段的重传定时器。

    6.3.2 坚持定时器

    上篇文章中已经提到了,主要是为了应付零窗口大小通知可能导致的死锁问题。如果接收端在向发送端发送了零窗口报文段后不久,接收端的接收缓存又有了一些存储空间,于是接收端向发送端发送了一个非零窗口大小的报文段,然而这个报文段在传送过程中丢失了,发送端没有收到该报文段,就一直等待接收端发送非零窗口的报文通知,而接收端并不知道报文段丢失了,而是觉得已经告诉发送端了,就会一直等待发送端发送数据,如果没有任何措施的话,这话死锁的局面会一直延续下去。

    为了解决这个问题,TCP为每一个连接设有一个坚持定时器(也叫持续计数器)。只要TCP连接的一方收到对方的零窗口通知,就启动坚持定时器。若坚持定时器设置的时间到期,就发送一个零窗口控测报文段(该报文段只有一个字节的数据,它有一个序号,但该序号永远不需要确认,因此该序号可以持续重传),之后会出现以下三种情况:

    1. 对方在收到探测报文段后,在对该报文段的确认中给出现在的窗口值,如果窗口值仍未零,则收到这个报文段的一方将坚持定时器的值加倍并重启。坚持计数器最大只能增加到约60秒,在此之后,每次收到零窗口通知,坚持计数器的值就定位60秒。

    2. 对方在收到探测报文段后,在对该报文段的确认中给出现在的窗口值,如果窗口不为零,那么死锁的僵局就被打破了。

    3. 该探测报文发出后,会同时启动重传定时器,如果重传定时器的时间到期,还没有收到接收到发来的响应,则超时重传探测报文。

    6.3.3 保活定时器

    保活定时器是为了应对两个TCP连接间出现长时间的没有数据传输的情况。如果客户已与服务器建立了TCP连接,但后来客户端主机突然故障,则服务器就不能再收到客户端发来的数据了,而服务器肯定不能这样永久地等下去,保活定时器就是用来解决这个问题的。服务器每收到一次客户端的数据,就重新设置保活定时器,通常为2小时,如果2小时没有收到客户端的数据,服务端就发送一个探测报文,以后每隔75秒发送一次,如果连续发送10次探测报文段后仍没有收到客户端的响应,服务器就认为客户端出现了故障,就可以终止这个连接。

    #### 6.3.4 2MSL定时器

    2MSL定时器测量一个连接处于TIME—WAIT黄台的时间,通常为2MSL(报文段寿命的两倍)。2MSL定时器的设置主要是为了确保发送的最后一个ACK报文段能够到达对方,并防止之前与本连接有关的由于延迟等原因而导致已失效的报文被误判为有效。

    6.4 TCP 滑动窗口

    窗口是缓存的一部分,用来暂时存放字节流。发送方和接收方各有一个窗口,接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小,发送方根据这个值和其它信息设置自己的窗口大小。

    发送窗口内的字节都允许被发送,接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认,那么就将发送窗口向右滑动一定距离,直到左部第一个字节不是已发送并且已确认的状态;接收窗口的滑动类似,接收窗口左部字节已经发送确认并交付主机,就向右滑动接收窗口。

    接收窗口只会对窗口内最后一个按序到达的字节进行确认,例如接收窗口已经收到的字节为 {31, 34, 35},其中 {31} 按序到达,而 {34, 35} 就不是,因此只对字节 31 进行确认。发送方得到一个字节的确认之后,就知道这个字节之前的所有字节都已经被接收。

    6.5 TCP 流量控制

    一般来说,我们总是希望数据传输的更快一些,但如果发送方把数据发送的很快,而接收方来不及接收,这就可能造成数据的丢失。流量控制就是让发送方的发送速率不要太快,让接收方来得及接收。

    接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。

    6.6 TCP 拥塞控制

    如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而导致网络拥塞程度更高。因此当出现拥塞时,应当控制发送方的速率。这一点和流量控制很像,但是出发点不同。流量控制是为了让接收方能来得及接收,而拥塞控制是为了降低整个网络的拥塞程度

    TCP 主要通过四个算法来进行拥塞控制:慢开始、拥塞避免、快重传、快恢复

    名词

    rwnd	滑动窗口
    cwnd 拥塞窗口
    ssthresh 慢启动门限
    MMS 最大报文段
    RRT 往返时间
    

    发送方需要维护一个叫做拥塞窗口(cwnd)的状态变量,注意拥塞窗口与发送方窗口的区别:拥塞窗口只是一个状态变量,实际决定发送方能发送多少数据的是发送方窗口。

    为了便于讨论,做如下假设:

    接收方有足够大的接收缓存,因此不会发生流量控制;
    虽然 TCP 的窗口基于字节,但是这里设窗口的大小单位为报文段。

    1. 慢开始与拥塞避免

    发送的最初执行慢开始,令 cwnd = 1,发送方只能发送 1 个报文段;当收到确认后,将 cwnd 加倍,因此之后发送方能够发送的报文段数量为:2、4、8 …(*慢启动, cwnd = 2)

    注意到慢开始每个轮次都将 cwnd 加倍,这样会让 cwnd 增长速度非常快,从而使得发送方发送的速度增长速度过快,网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh,当 cwnd >= ssthresh 时,进入拥塞避免,每个轮次只将 cwnd 加 1。(当cwnd < ssthresh时,*2,否则 +1 )

    如果出现了超时,则令 ssthresh = cwnd / 2,然后重新执行慢开始。

    1. 快重传与快恢复

    快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认(重复发送对前面有序部分的确认),而不是等待自己发送数据时才进行稍待确认,也不是累积收到的报文发送累积确认,如果发送方连续收到三个重复确认,就应该立即重传对方未收到的报文段(有收到重复确认,说明后面的报文段都送达了,只有中间丢失的报文段没送达)。

    在接收方,要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2,此时收到 M4,应当发送对 M2 的确认。
    在发送方,如果收到三个重复确认,那么可以知道下一个报文段丢失,此时执行快重传,立即重传下一个报文段。例如收到三个 M2,则 M3 丢失,立即重传 M3。
    在这种情况下,只是丢失个别报文段,而不是网络拥塞。因此执行快恢复,令 ssthresh = cwnd / 2 ,cwnd = ssthresh,注意到此时直接进入拥塞避免。

    慢开始和快恢复的快慢指的是 cwnd 的设定值,而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1,而快恢复 cwnd 设定为 ssthresh。


    问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?
    答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

    问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

    1. 为了保证A发送的最后一个ACK报文段能够到达B。该ACK报文段很有可能丢失,因而使处于在LAST—ACK状态的B收不到对已发送的FIN+ACK报文段的确认,B可能会重传这个FIN+ACK报文段,而A就在这2MSL时间内收到这个重传的FIN+ACK报文段,接着A重传一次确认,重新启动2MSL计时器,最后A和B都进入CLOSED状态。如果A在TIME—WAIT状态不等待一段时间就直接释放连接,到CLOSED状态,那么久无法收到B重传的FIN+ACK报文段,也就不会再发送一次确认ACK报文段,B就无法正常进入CLOSED状态。
       2. 防止已失效的请求连接出现在本连接中。在连接处于2MSL等待时,任何迟到的报文段将被丢弃,因为处于2MSL等待的、由该插口(插口是IP和端口对的意思,socket)定义的连接在这段时间内将不能被再用,这样就可以使下一个新的连接中不会出现这种旧的连接之前延迟的报文段。

    补充:
       当客户端执行主动关闭并进入TIME—WAIT是正常的,服务端执行被动关闭,不会进入TIME—WAIT状态,这说明,如果终止了一个客户程序,并立即重启该客户程序,则新的客户程序将不再重用相同的本地端口,而是使用新的端口,这不会带来什么问题,因为客户端使用本地端口,而并不关心这个端口是多少。但对于服务器来说,情况就不同了,服务器总是用我们熟知的端口,那么在2MSL时间内,重启服务器就会出错,为了避免这个错误,服务器给出了一个平静时间的概念,这是说在2MSL时间内,虽然可以重新启动服务器,但是这个服务器还是要平静的等待2MSL时间的过去才能进行下一次连接。

    问题三】TCP和UDP的优缺点及区别

    TCP的优点: 可靠,稳定 TCP的可靠体现在TCP在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完后,还会断开连接用来节约系统资源。

    TCP的缺点: 慢,效率低,占用系统资源高,易被攻击 TCP在传递数据之前,要先建连接,这会消耗时间,而且在数据传递时,确认机制、重传机制、拥塞控制机制等都会消耗大量的时间,而且要在每台设备上维护所有的传输连接,事实上,每个连接都会占用系统的CPU、内存等硬件资源。 而且,因为TCP有确认机制、三次握手机制,这些也导致TCP容易被人利用,实现DOS、DDOS、CC等攻击。

    UDP的优点: 快,比TCP稍安全 UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制,UDP是一个无状态的传输协议,所以它在传递数据时非常快。没有TCP的这些机制,UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的,比如:UDP Flood攻击

    UDP的缺点: 不可靠,不稳定 因为UDP没有TCP那些可靠的机制,在数据传递时,如果网络质量不好,就会很容易丢包。 基于上面的优缺点,那么: 什么时候应该使用TCP: 当对网络通讯质量有要求的时候,比如:整个数据要准确无误的传递给对方,这往往用于一些要求可靠的应用,比如HTTP、HTTPS、FTP等传输文件的协议,POP、SMTP等邮件传输的协议。 在日常生活中,常见使用TCP协议的应用如下: 浏览器,用的HTTP FlashFXP,用的FTP Outlook,用的POP、SMTP Putty,用的Telnet、SSH QQ文件传输

    什么时候应该使用UDP: 当对网络通讯质量要求不高的时候,要求网络通讯速度能尽量的快,这时就可以使用UDP。 比如,日常生活中,常见使用UDP协议的应用如下: QQ语音 QQ视频 TFTP ……

    有些应用场景对可靠性要求不高会用到UPD,比如长视频,要求速率

    TCP与UDP的区别

    1. 基于连接与无连接;
    2. 对系统资源的要求(TCP较多,UDP少);
    3. UDP程序结构较简单;
    4. 流模式与数据报模式 ;
    5. TCP保证数据正确性,UDP可能丢包,TCP保证数据顺序,UDP不保证。

    问题四】 为什么一定要进行三次握手?

    前两次的握手很显然是必须的,主要是最后一次,即客户端收到服务端发来的确认后为什么还要想服务端再发送一次确认呢?这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判。
    考虑如下的情况:客户端发送了一个连接请求报文段到服务端,但是在某些网络节点上长时间滞留了,而后客户端又超时重发了一个连接请求报文段该服务端,而后正常建立连接,数据传输完毕,并释放了连接。如果这时候第一次发送的请求报文段延迟了一段时间后,又到了服务端,很显然,这本是一个早已失效的报文段,但是服务端收到后会误以为客户端又发出了一次连接请求,于是向客户端发出确认报文段,并同意建立连接。假设不采用三次握手,这时服务端只要发送了确认,新的连接就建立了,但由于客户端比你更没有发出建立连接的请求,因此不会理会服务端的确认,也不会向服务端发送数据,而服务端却认为新的连接已经建立了,并在一直等待客户端发送数据,这样服务端就会一直等待下去,直到超出保活计数器的设定值,而将客户端判定为出了问题,才会关闭这个连接。这样就浪费了很多服务器的资源。而如果采用三次握手,客户端就不会向服务端发出确认,服务端由于收不到确认,就知道客户端没有要求建立连接,从而不建立该连接。

    展开全文
  • Internet 传输层协议

    千次阅读 2009-01-07 17:04:00
    第 3 章 Internet 传输层协议 本章介绍了 Internet 传输层的两个重要协议 TCP 和 UDP ,包括这两种协议的报文格式和工作原理。特别地,本章详细介绍了 TCP 的连接建立与关闭,以及连接建立与关闭过程的状态转换。 ...
     
    

    第 3 章 Internet 传输层协议

       本章介绍了 Internet 传输层的两个重要协议 TCP 和 UDP ,包括这两种协议的报文格式和工作原理。特别地,本章详细介绍了 TCP 的连接建立与关闭,以及连接建立与关闭过程的状态转换。

    3.1 引言

       Internet 在传输层有两种主要的协议:一种是面向连接的协议 TCP ,一种是无连接的协议 UDP 。由于 UDP 基本上是在 IP 的基础上增加一个短的报头而得到的,比较简单,因此本章将先介绍 UDP ,然后再重点介绍 TCP 。

       在TCP/IP 协议簇中, IP 提供在主机之间传送数据报的能力,每个数据报根据其目的主机的 IP 地址进行在 Internet 中的路由选择。传输层协议为应用层提供的是进程之间的通信服务。为了在给定的主机上能识别多个目的地址,同时允许多个应用程序在同一台主机上工作并能独立地进行数据报的发送和接收, TCP/UDP 提供了应用程序之间传送数据报的基本机制,它们提供的协议端口能够区分一台机器上运行的多个程序。

       也就是说, TCP/UDP 使用 IP 地址标识网上主机,使用端口号来标识应用进程,即 TCP/UDP 用主机 IP 地址和为应用进程分配的端口号来标识应用进程。端口号是 16 位的无符号整数, TCP 的端口号和 UDP 的端口号是两个独立的序列。尽管相互独立,如果 TCP 和 UDP 同时提供某种知名服务,两个协议通常选择相同的端口号。这纯粹是为了使用方便,而不是协议本身的要求。利用端口号,一台主机上多个进程可以同时使用 TCP/UDP 提供的传输服务,并且这种通信是端到端的,它的数据由 IP 传递,但与 IP 数据报的传递路径无关。网络通信中用一个三元组可以在全局唯一标志一个应用进程:

    (协议,本地地址,本地端口号)

       这样一个三元组,叫做一个半相关( half-association ),它指定连接的每半部分。一个完整的网间进程通信需要由两个进程组成,并且只能使用同一种高层协议。也就是说,不可能通信的一端用 TCP 协议,而另一端用 UDP 协议。因此一个完整的网间通信需要一个五元组来标识:

    (协议,本地地址,本地端口号,远地地址,远地端口号)

       这样一个五元组,叫做一个相关( association ),即两个协议相同的半相关才能组合成一个合适的相关,或完全指定组成一连接。

       端口号的分配是一个重要问题。有两种基本分配方式:第一种叫全局分配,这是一种集中控制方式,由一个公认的中央机构根据用户需要进行统一分配,并将结果公布于众。第二种是本地分配,又称动态连接,即进程需要访问传输层服务时,向本地操作系统提出申请,操作系统返回一个本地唯一的端口号,进程再通过合适的系统调用将自己与该端口号联系起来(绑扎)。 TCP/UDP 端口号的分配中综合了上述两种方式。 TCP/UDP 将端口号分为两部分,少量的作为保留端口,以全局方式分配给服务进程。因此,每一个标准服务器都拥有一个全局公认的端口(即周知口, well-known port ),即使在不同机器上,其端口号也相同。剩余的为自由端口,以本地方式进行分配。表 3-1 列出了常用的 TCP/UDP 周知端口号。

    表 3-1 常用周知端口号列表

    端口号

    协议

    关键词

    UNIX 关键词

    描述

    1

    TCP

    TCPMUX

    TCP 复用器

    7

    TCP/UDP

    ECHO

    echo

    回送

    9

    TCP/UDP

    DISCARD

    discard

    丢弃

    15

    TCP/UDP

    netstat

    网络状态程序

    20

    TCP

    FTP-DATA

    ftp-data

    文件传输协议(数据)

    21

    TCP

    FTP

    ftp

    文件传输协议

    22

    TCP/UDP

    SSH

    ssh

    安全 Shell 远程登录协议

    23

    TCP

    TELNET

    telnet

    远程登录

    25

    TCP

    SMTP

    smtp

    简单邮件传输协议

    37

    TCP/UDP

    time

    时间

    42

    TCP/UDP

    NAMESERVER

    name

    主机名字服务器

    43

    TCP/UDP

    NICNAME

    whois

    是谁

    53

    TCP/UDP

    DOMAIN

    nameserver

    域名服务器

    67

    UDP

    BOOTPS

    bootps

    引导协议服务器

    68

    UDP

    BOOTPC

    bootpc

    引导协议客户

    69

    UDP

    TFTP

    tftp

    简单文件传送协议

    79

    TCP

    FINGER

    finger

    Finger

    80

    TCP

    HTTP

    http

    超文本传输协议

    88

    TCP

    KERBEROS

    kerberos

    Kerberos 协议

    93

    TCP

    DCP

    设备控制协议

    101

    TCP

    HOSTNAME

    hostnames

    NIC 主机名字服务器

    110

    TCP

    POP3

    pop3

    邮局协议版本 3

    111

    TCP/UDP

    SUNRPC

    sunrpc

    Sun Microsystems RPC

    119

    TCP

    NNTP

    nntp

    USENET 新闻传送协议

    123

    UDP

    NTP

    ntp

    网络时间协议

    139

    TCP

    NETBIOS-SSN

    NETBIOS 会话协议

    161

    UDP

    snmp

    简单网络管理协议

    162

    UDP

    snmp-trap

    SNMP 陷阱

    389

    TCP

    LDAP

    ldap

    轻量目录访问协议

    443

    TCP

    HTTPS

    https

    安全 HTTP 协议

    513

    UDP

    who

    UNIX rwho daemon

    514

    UDP

    syslog

    系统日志

    525

    UDP

    timed

    UNIX time daemon

    546

    TCP

    DHCP-CLIENT

    dhcp-client

    动态主机配置协议客户

    547

    TCP

    DHCP-SERVER

    dhcp-server

    动态主机配置协议服务器

     

       TCP 是一种有连接的传输服务,它提供可靠的传输,是大部分 Internet 应用的基础。 UDP 提供的是一种无连接服务,每个数据包独立传输,在传统的应用中因为不能像 TCP 那样保证数据的可靠传输而应用较少。但是对于新的实时视频、音频数据的传输来说,因为不能容忍 TCP 重传带来的时延,常常建立在 UDP 之上。 UDP 为互联网上实时视频、音频服务提供了极好的实验环境。

    3.2 用户数据报协议 UDP

       UDP(User Datagram Protocol) 是一个简单的面向数据报的传输层协议,进程的每个输出操作都正好产生一个 UDP 数据报,并组装成一份待发送的 IP 数据报。 UDP 不提供可靠性,它把应用程序传给 IP 层的数据发送出去,但是并不保证它们能到达目的地。应用程序必须关心 IP 数据报的长度。如果它超过网络的 MTU ,那么就要对 IP 数据报进行分片。 RFC 768 [Postel 1980] 是 UDP 的正式规范。

    3.2.1 UDP 报文格式

       每个 UDP 报文成为一个用户数据报,分 UDP 报头和 UDP 数据区两部分。报头由四个 16 位长的字段组成,分别说明该报文的源端口、目的端口、报文长度以及校验和。 UDP 报文格式如图 3-1 所示。

    0

    16 31

    UDP 源端口

    UDP 目的端口

    UDP 报文长度

    UDP 校验和

    数据

     

    图 3-1 UDP 报文格式

     

       UDP 源端口字段和目的端口字段包含了 16 位的 UDP 协议端口号,表示发送进程和接收进程。 UDP 长度字段指的是 UDP 报头和 UDP 数据的字节长度,该字段的最小值为 8 字节(发送一份 0 字节的 UDP 数据报是可以的)。 UDP 检验和覆盖 UDP 报头和 UDP 数据。 UDP 和 TCP 在报头中都有覆盖它们报头和数据的检验和。 UDP 的检验和是可选的,如果该字段值为 0 表明不进行校验。一般来说,使用校验和字段是必要的。

    3.2.2 UDP 的封装与协议的分层

       在第 1 章介绍的 TCP/IP 协议层次结构模型中(参见图 1-3 ), UDP 位于 IP 层之上。应用程序访问 UDP 层,然后使用 IP 层传送数据报,如图 3-2 所示。

       将 UDP 层放在 IP 层之上,表示一个 UDP 报文在 Internet 中传输时要封装到 IP 数据报中。最后,网络接口层将数据包封装到一个帧中再进行物理传输通道上的传输。封装过程如图 3-3 所示。

     

     

    概念性层次

     

    UDP 报头

    UDP 数据区

    应用

     

    用户数据报( UDP )

     

    IP 报头

    IP 数据区

    互联网( IP )

     

    网络接口

     

    帧头

    帧数据区

    图 3-2 分层模型中的 UDP 层

    图 3-3 UDP 的封装

     

       由图可知, IP 层的报头指明了源主机和目的主机的地址,而 UDP 层的报头指明了主机上的源端口和目的端口。 IP 层和 UDP 层之间的职责是清楚而明确的: IP 层指负责在 Internet 上的一对主机之间进行数据传输,而 UDP 层只负责对一台主机上的复用的多个源端口或目的端口进行区分。

    3.2.3 UDP 的复用、分解与端口

       UDP 也提供复用和分解的功能。它接收多个应用程序送来的数据报,把它们送给 IP 层区传输,同时它接受 IP 层送来的 UDP 数据报,把它们送给对应的应用程序。

    从概念上讲,所有的 UDP 软件与应用程序之间的复用和分解都要通过端口机制来实现。实际上每个应用程序在发送数据报之前必须与操作系统进行协商以获得协议端口和相应的端口号。凡是利用指定的端口发送数据报的应用程序都要把端口号放入 UDP 报文中的源端口字段中。

    UDP 的分解操作如图 3-4 所示, UDP 从 IP 层接收了数据报之后,根据 UDP 的目的端口号进行分解操作。

    3.3 传输控制协议 TCP

       TCP(Transfer Control Protocol) 是专门设计用于在不可靠的 Internet 上提供可靠的、端到端的字节流通信的协议。 Internet 不同于一个单独的网络,不同部分可能具有不同的拓扑结构、带宽、延迟、分组大小以及其它特性。 TCP 被设计成能动态满足 Internet 的要求,并且足以健壮地面对多种出错。 RFC 793 [Postel 1981] 是 TCP 的正式规范。

    3.3.1 可靠的数据流传输

       UDP 提供的服务是不可靠的数据传送服务,当传送过程中出现差错、网络软件发生故障或网络负载太重时,分组可能会丢失,数据可能被破坏。这就需要应用程序负责进行差错检测和恢复工作,对传输数据量很大的应用来说,采用这种不可靠的数据传输是不合适的。因此需要有一种可靠的数据流传输方法,这就是 TCP 。 TCP 提供的可靠传输服务有如下五个特征:面向数据流:当两个应用程序传输大量数据时,将这些数据当作一个可划分为字

    • 节的比特流。在传输时,在接收方收到的字节流与发送方发出的完全一样。
    • 虚电路连接:在传输开始之前,接收应用程序和发送应用程序都要与操作系统进行交互,双方操作系统的协议软件模块通过在互联网络上传送报文来进行通信,进行数据传输的准备与建立连接。通常用“虚电路”这个术语来描述这种连接,因为对应用程序来说这种连接好像是一条专用线路,而实际上是由数据流传输服务提供的可靠的虚拟连接。
    • 有缓冲的传输:使用虚电路服务来发送数据流的应用程序不断地向协议软件提交以字节为单位的数据,并放在缓冲区中。当累积到足够多的数据时,将它们组成大小合理的数据报,再发送到互联网上传输。这样可提高传输效率,减少网络流量。当应用程序传送特别大的数据块时,协议软件将它们划分为适合于传输的较小的数据块,并且保证在接收端收到的数据流与发送的顺序完全相同。
    • 无结构的数据流: TCP/IP 协议并未区分结构化的数据流。使用数据流服务的应用程序必须在传输数据前就了解数据流的内容,并对其格式进行协商。
    • 全双工连接: TCP/IP 流服务提供的连接功能是双向的,这种连接叫做全双工连接。对一个应用程序而言,全双工连接包括了两个独立的、流向相反的数据流,而且这两个数据流之间不进行显式的交互。全双工连接的优点在于底层协议软件能够在与送来数据流方向相反方向的数据流中传输控制信息,这种捎带的方式降低了网络流量。
    • TCP 采用一种名为“带重传功能的肯定确认( positive acknowledge with retransmission )”的技术作为提供可靠数据传输服务的基础。这项技术要求接收方收到数据之后向源站回送确认信息 ACK 。发送方对发出的每个分组都保存一份记录,在发送下一个分组之前等待确认信息。发送方还在送出分组的同时启动一个定时器,并在定时器的定时期满而确认信息还没有到达的情况下,重发刚才发出的分组。图 3-5 表示带重传功能的肯定确认协议传输数据的情况,图 3-6 表示分组丢失引起超时和重传。为了避免由于网络延迟引起迟到的确认和重复的确认,协议规定在确认信息中稍带一个分组的序号,使接收方能正确将分组与确认关联起来。

    3.3.2 滑动窗口概念

       从图 3-5 可以看出,虽然网络具有同时进行双向通信的能力,但由于在接到前一个分组的确认信息之前必须推迟下一个分组的发送,简单的肯定确认协议浪费了大量宝贵的网络带宽。为此, TCP 使用滑动窗口的机制来提高网络吞吐量,同时解决端到端的流量控制。

       滑动窗口技术是简单的带重传的肯定确认机制的一个更复杂的变形,它允许发送方在等待一个确认信息之前可以发送多个分组。如图 3-7 所示,发送方要发送一个分组序列,滑动窗口协议在分组序列中放置一个固定长度的窗口,然后将窗口内的所有分组都发送出去;当发送方收到对窗口内第一个分组的确认信息时,它可以向后滑动并发送下一个分组;随着确认的不断到达,窗口也在不断的向后滑动。

    图 3-7 (a) 窗口内包括 8 个分组的滑动窗口协议

    (b) 收到对 1 号分组的确认信息后,窗口滑动,使得 9 号分组也能被发送

     

       滑动窗口协议的效率与窗口大小和网络接收分组的速度有关。图 3-8 表示了一个窗口大小为 3 的的滑动窗口协议软件的动作示意图。发送方在收到确认之前就发出了三个分组,在收到第一个分组的确认 ACK1 后,又发送了第四个分组。比较图 3-5 和图 3-8 ,就可以看出使用滑动窗口后网络吞吐量的提高。实际上,当窗口大小等于 1 时,滑动窗口协议就等同于简单的肯定确认协议。通过增加窗口大小,可以完全消除网络的空闲状态。在稳定的情况下,发送方能以网络传输分组的最快能力来发送分组。

    图 3-8 使用窗口大小为 3 的滑动窗口协议传输分组示例

    3.3.3 TCP 报文格式

       两台计算机上的 TCP 软件之间传输的数据单元称为报文段。 TCP 通过报文段的交互来建立连接、传输数据、发出确认、通告窗口大小以及关闭连接。 TCP 报文分为两部分,前面是报头,后面是数据。报头的前 20 个字节格式是固定的,后面是可能的选项,数据长度最大为 65535 – 20 – 20 = 65495 字节,其中第一个 20 指 IP 头,第二个 20 指 TCP 头。不带任何数据的报文也是合法的,一般用于确认和控制报文。图 3-9 给出了 TCP 报文的布局格式。每个字段的意义简介如下:

    0

    31

    源端口( source port )号

    目的端口( destination port )号

    顺序号( sequence number )

    确认号( acknowledgement number )

    TCP 报头长度

    保留

    URG

    ACK

    PSH

    RST

    SYN

    FIN

    窗口大小( window size )

    校验和( checksum )

    紧急指针( urgent pointer )

    选项+填充( 0 或多个 32 位字)

    数据( 0 或多个字节)

    图 3-9 TCP 报头格式

     

    • 源端口号( 16 位):它(连同源主机 IP 地址)标识源主机的一个应用进程。
    • 目的端口号( 16 位):它(连同目的主机 IP 地址)标识目的主机的一个应用进程。这两个值加上 IP 报头中的源主机 IP 地址和目的主机 IP 地址唯一确定一个 TCP 连接。
    • 顺序号( 32 位):用来标识从 TCP 源端向 TCP 目的端发送的数据字节流,它表示在这个报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动,则 TCP 用顺序号对每个字节进行计数。序号是 32bit 的无符号数,序号到达 2 32 - 1 后又从 0 开始。当建立一个新的连接时, SYN 标志变 1 ,顺序号字段包含由这个主机选择的该连接的初始顺序号 ISN ( Initial Sequence Number )。
    • 确认号( 32 位):包含发送确认的一端所期望收到的下一个顺序号。因此,确认序号应当是上次已成功收到数据字节顺序号加 1 。只有 ACK 标志为 1 时确认序号字段才有效。 TCP 为应用层提供全双工服务,这意味数据能在两个方向上独立地进行传输。因此,连接的每一端必须保持每个方向上的传输数据顺序号。
    • TCP 报头长度( 4 位):给出报头中 32bit 字的数目,它实际上指明数据从哪里开始。需要这个值是因为任选字段的长度是可变的。这个字段占 4bit ,因此 TCP 最多有 60 字节的首部。然而,没有任选字段,正常的长度是 20 字节。
    • 保留位( 6 位):保留给将来使用,目前必须置为 0 。
    • 控制位( control flags , 6 位):在 TCP 报头中有 6 个标志比特,它们中的多个可同时被设置为 1 。依次为:
    • URG :为 1 表示紧急指针有效,为 0 则忽略紧急指针值。
    • ACK :为 1 表示确认号有效,为 0 表示报文中不包含确认信息,忽略确认号字段。
    • PSH :为 1 表示是带有 PUSH 标志的数据,指示接收方应该尽快将这个报文段交给应用层而不用等待缓冲区装满。
    • RST :用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报文段和拒绝连接请求。一般情况下,如果收到一个 RST 为 1 的报文,那么一定发生了某些问题。
    • SYN :同步序号,为 1 表示连接请求,用于建立连接和使顺序号同步( synchronize )。
    • FIN :用于释放连接,为 1 表示发送方已经没有数据发送了,即关闭本方数据流。
    • 窗口大小( 16 位):数据字节数,表示从确认号开始,本报文的源方可以接收的字节数,即源方接收窗口大小。窗口大小是一个 16bit 字段,因而窗口大小最大为 65535
    • .. 字节。
    • 校验和( 16 位):此校验和是对整个的 TCP 报文段,包括 TCP 头部和 TCP 数据,以 16 位字进行计算所得。这是一个强制性的字段,一定是由发送端计算和存储,并由接收端进行验证。
    • 紧急指针( 16 位):只有当 URG 标志置 1 时紧急指针才有效。紧急指针是一个正的偏移量,和顺序号字段中的值相加表示紧急数据最后一个字节的序号。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。
    • 选项:最常见的可选字段是最长报文大小,又称为 MSS(Maximum Segment Size) 。每个连接方通常都在通信的第一个报文段(为建立连接而设置 SYN 标志的那个段)中指明这个选项,它指明本端所能接收的最大长度的报文段。选项长度不一定是 32 位字的整数倍,所以要加填充位,使得报头长度成为整字数。
    • 数据: TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时,双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送,也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中,也会发送不带任何数据的报文段。
    3.4 TCP 连接建立与关闭

       TCP 是一个面向连接的协议,无论哪一方向另一方发送数据之前,都必须先在双方之间建立一条连接。本节将详细讨论一个TCP 连接是如何建立的以及通信结束后是如何终止的。

    3.4.1 建立一个 TCP 连接

       TCP使用三次握手 ( three-way handshake ) 协议来建立连接,图 3-10 描述了三次握手的报文序列。这三次握手为:

    • 请求端(通常称为客户)发送一个 SYN 报文段( SYN 为 1 )指明客户打算连接的服务器的端口,以及初始顺序号( ISN )。
    • 服务器发回包含服务器的初始顺序号的 SYN 报文段( SYN 为 1 )作为应答。同时,将确认号设置为客户的 ISN 加 1 以对客户的 SYN 报文段进行确认( ACK 也为 1 )。
    • 客户必须将确认号设置为服务器的 ISN 加 1 以对服务器的 SYN 报文段进行确认( ACK 为 1 ),该报文通知目的主机双方已完成连接建立。

       发送第一个 SYN 的一端将执行主动打开( active open ),接收这个 SYN 并发回下一个 SYN 的另一端执行被动打开( passive open )。另外, TCP 的握手协议被精心设计为可以处理同时打开( simultaneous open ),对于同时打开它仅建立一条连接而不是两条连接。因此,连接可以由任一方或双方发起,一旦连接建立,数据就可以双向对等地流动,而没有所谓的主从关系。

       三次握手协议是连接两端正确同步的充要条件。因为 TCP 建立在不可靠的分组传输服务之上,报文可能丢失、延迟、重复和乱序,因此协议必须使用超时和重传机制。如果重传的连接请求和原先的连接请求在连接正在建立时到达,或者当一个连接已经建立、使用和结束之后,某个延迟的连接请求才到达,就会出现问题。采用三次握手协议(加上这样的规则:在连接建立之后 TCP 就不再理睬又一次的连接请求)就可以解决这些问题。

       三次握手协议可以完成两个重要功能:它确保连接双方做好传输准备,并使双方统一了初始顺序号。初始顺序号是在握手期间传输顺序号并获得确认:当一端为建立连接而发送它的 SYN 时,它为连接选择一个初始顺序号;每个报文段都包括了顺序号字段和确认号字段,这使得两台机器仅仅使用三个握手报文就能协商好各自的数据流的顺序号。一般来说, ISN 随时间而变化,因此每个连接都将具有不同的 ISN 。

    3.4.2 关闭一个 TCP 连接

       TCP 连接建立起来后,就可以在两个方向传送数据流。当 TCP 的应用进程再没有数据需要发送时,就发关闭命令。 TCP 通过发送控制位 FIN=1 的数据片来关闭本方数据流,但还可以继续接收数据,直到对方关闭那个方向的数据流,连接就关闭。

       TCP 协议使用修改的三次握手协议来关闭连接, 如图 3-11 所示,即终止一个连接要经过 4 次握手。这是因为 TCP 的半关闭( half-close )造成的。由于一个 TCP 连接是全双工(即数据在两个方向上能同时传递),因此每个方向必须单独地进行关闭。关闭的原则就是当一方完成它的数据发送任务后就能发送一个 FIN 来终止这个方向连接。当一端收到一个 FIN ,它必须通知应用层另一端已经终止了那个方向的数据传送。发送 FIN 通常是应用层进行关闭的结果。

    从一方的 TCP 来说,连接的关闭有三种情况:

    •  本方启动关闭

       收到本方应用进程的关闭命令后, TCP 在发送完尚未处理的报文段后,发 FIN = 1 的报文段给对方,且 TCP 不再受理本方应用进程的数据发送。在 FIN 以前发送的数据字节,包括 FIN ,都需要对方确认,否则要重传。注意 FIN 也占一个顺序号。一旦收到对方对 FIN 的确认以及对方的 FIN 报文段,本方 TCP 就对该 FIN 进行确认,在等待一段时间,然后关闭连接。等待是为了防止本方的确认报文丢失,避免对方的重传报文干扰新的连接。

    •  对方启动关闭

       当 TCP 收到对方发来的 FIN 报文时,发 ACK 确认此 FIN 报文,并通知应用进程连接正在关闭。应用进程将以关闭命令响 应。 TCP 在发送完尚未处理的报文段后,发一个 FIN 报文给对方 TCP ,然后等待对方对 FIN 的确认,收到确认后关闭连接。若对方的确认未及时到达,在等待一段时间后也关闭连接。

    •  双方同时启动关闭

       连接双方的应用进程同时发关闭命令,则双方 TCP 在发送完尚未处理的报文段后,发送 FIN 报文。各方 TCP 在 FIN 前所发报文都得到确认后,发 ACK 确认它收到的 FIN 。各方在收到对方对 FIN 的确认后,同样等待一段时间再关闭连接。这称之为同时关闭( simultaneous close )。

    3.4.3 TCP 状态机

       TCP 协议的操作可以使用一个具有 11 种状态的有限状态机( Finite State Machine )来表示,图 3-12 描述了 TCP 的有限状态机,图中的圆角矩形表示状态,箭头表示状态之间的转换,各状态的描述如表 3-2 所示。图中用粗线表示客户端主动和被动的服务器端建立连接的正常过程:客户端的状态变迁用粗实线,服务器端的状态变迁用粗虚线。细线用于不常见的序列,如复位、同时打开、同时关闭等。图中的每条状态变换线上均标有“事件/动作”:事件是指用户执行了系统调用( CONNECT 、 LISTEN 、 SEND 或 CLOSE )、收到一个报文段( SYN 、 FIN 、 ACK 或 RST )、或者是出现了超过两倍最大的分组生命期的情况;动作是指发送一个报文段( SYN 、 FIN 或 ACK )或什么也没有(用“-”表示)。

    图 3-12 TCP 有限状态机。粗实线表示客户的正常路径;
    粗虚线表示服务器的正常路径;细线表示不常见的事件。

       每个连接均开始于 CLOSED 状态。当一方执行了被动的连接原语( LISTEN )或主动的连接原语( CONNECT )时,它便会脱离 CLOSED 状态。如果此时另一方执行了相对应的连接原语,连接便建立了,并且状态变为 ESTABLISHED 。任何一方均可以首先请求释放连接,当连接被释放后,状态又回到了 CLOSED 。

     

    表 3-2 TCP 状态表

    状 态

    描 述

    CLOSED

    关闭状态,没有连接活动或正在进行

    LISTEN

    监听状态,服务器正在等待连接进入

    SYN RCVD

    收到一个连接请求,尚未确认

    SYN SENT

    已经发出连接请求,等待确认

    ESTABLISHED

    连接建立,正常数据传输状态

    FIN WAIT 1

    (主动关闭)已经发送关闭请求,等待确认

    FIN WAIT 2

    (主动关闭)收到对方关闭确认,等待对方关闭请求

    TIMED WAIT

    完成双向关闭,等待所有分组死掉

    CLOSING

    双方同时尝试关闭,等待对方确认

    CLOSE WAIT

    (被动关闭)收到对方关闭请求,已经确认

    LAST ACK

    (被动关闭)等待最后一个关闭确认,并等待所有分组死掉

     

    1. 正常状态转换

       我们用图 3-13 来显示在正常的 TCP 连接的建立与终止过程中,客户与服务器所经历的不同状态。读者可以对照图 3-12 来阅读,使用图 3-12 的状态图来跟踪图 3-13 的状态变化过程,以便明白每个状态的变化:

    • 服务器端首先执行 LISTEN 原语进入被动打开状态( LISTEN ),等待客户端连接;
    • 当客户端的一个应用程序发出 CONNECT 命令后,本地的 TCP 实体为其创建一个连接记录并标记为 SYN SENT 状态,然后给服务器发送一个 SYN 报文段;
    • 服务器收到一个 SYN 报文段,其 TCP 实体给客户端发送确认 ACK 报文段同时发送一个 SYN 信号,进入 SYN RCVD 状态;
    • 客户端收到 SYN + ACK 报文段,其 TCP 实体给服务器端发送出三次握手的最后一个 ACK 报文段,并转换为 ESTABLISHED 状态;
    • 服务器端收到确认的 ACK 报文段,完成了三次握手,于是也进入 ESTABLISHED 状态。

      在此状态下,双方可以自由传输数据。当一个应用程序完成数据传输任务后,它需要关闭 TCP 连接。假设仍由客户端发起主动关闭连接。

    • 客户端执行 CLOSE 原语,本地的 TCP 实体发送一个 FIN 报文段并等待响应的确认(进入状态 FIN WAIT 1 );
    • 服务器收到一个 FIN 报文段,它确认客户端的请求发回一个 ACK 报文段,进入 CLOSE WAIT 状态;
    • 客户端收到确认 ACK 报文段,就转移到 FIN WAIT 2 状态,此时连接在一个方向上就断开了;
    • 服务器端应用得到通告后,也执行 CLOSE 原语关闭另一个方向的连接,其本地 TCP 实体向客户端发送一个 FIN 报文段,并进入 LAST ACK 状态,等待最后一个 ACK 确认报文段;
    • 客户端收到 FIN 报文段并确认,进入 TIMED WAIT 状态,此时双方连接均已经断开,但 TCP 要等待一个 2 倍报文段最大生存时间 MSL ( Maximum Segment Lifetime ),确保该连接的所有分组全部消失,以防止出现确认丢失的情况。当定时器超时后, TCP 删除该连接记录,返回到初始状态( CLOSED )。
    • 服务器收到最后一个确认 ACK 报文段,其 TCP 实体便释放该连接,并删除连接记录,返回到初始状态( CLOSED )。

     

    2. 同时打开:

       尽管发生的可能性极小,两个应用程序同时彼此执行主动打开的情况还是可能的。每一方必须发送一个 SYN ,且这些 SYN 必须传递给对方。这需要每一方使用一个对方周知的端口作为本地端口。例如,主机 A 中的一个应用程序使用本地端口 7777 ,并与主机 B 的端口 8888 执行主动打开。主机 B 中的应用程序则使用本地端口 8888 ,并与主机 A 的端口 7777 执行主动打开。 TCP 是特意设计为了可以处理同时打开,对于同时打开它仅建立一条连接而不是两条连接(其他的协议族,最突出的是 OSI 传输层,在这种情况下将建立两条连接而不是一条连接)。

       当出现同时打开的情况时,状态变迁与图 3-13 所示的不同。两端几乎在同时发送 SYN ,并进入 SYN_SENT 状态。当每一端收到 SYN 时,状态变为 SYN_RCVD ,同时它们都再发 SYN 并对收到的 SYN 进行确认。当双方都收到 SYN 及相应的 ACK 时,状态都变迁为 ESTABLISHED 。图 3-14 显示了这些状态变迁过程。

    图 3-14 同时打开期间报文段的交换

     

       一个同时打开的连接需要交换 4 个报文段,比正常的三次握手多一个。此外,要注意的是我们没有将任何一端称为客户或服务器,因为每一端既是客户又是服务器。

     

    3. 同时关闭:

       正常情况下都是由一方(通常但不总是客户方)发送第一个 FIN 执行主动关闭,但双方都执行主动关闭也是可能的, TCP 协议也允许这样的同时关闭。

       在图 3-12 中,当两端应用层同时发出关闭命令时,两端均从 ESTABLISHED 变为 FIN_WAIT_1 。这将导致双方各发送一个 FIN ,两个 FIN 经过网络传送后分别到达另一端。收到 FIN 后,状态由 FIN_WAIT_1 变迁到 CLOSING ,并发送最后的 ACK 。当收到最后的 ACK 时,状态变化为 TIME_WAIT 。图 3-15 总结了这些状态的变化,从图中可以看出同时关闭与正常关闭使用的报文段交换数目相同。

    图 3-15 同时关闭期间的报文段交换

     

    4. 其它情况:

    • 服务方打开:从 LISTEN 到 SYN_SENT 的变迁是正确的,它由服务器端主动发出 SYN 报文段,但 Berkeley 版的 TCP 软件并不支持它。
    • 重置连接(复位):只有当 SYN_RCVD 状态是从 LISTEN 状态(正常情况)进入,而不是从 SYN_SENT 状态(同时打开)进入时,从 SYN_RCVD 回到 LISTEN 的状态变迁才是有效的。这意味着如果我们执行被动打开(进入 LISTEN ),收到一个 SYN ,发送一个带 ACK 的 SYN (进入 SYN_RCVD ),然后收到一个 RST ,而不是一个 ACK ,便又回到 LISTEN 状态并等待另一个连接请求的到来。
    • 快速关闭:在主动关闭后的 FIN_WAIT_1 状态,如果收到的报文段不仅是 ACK ,而且还包括对方的 FIN 信号,则直接进入 TIME_WAIT 状态,给对方发送 ACK 报文段,然后等待超时。

     

       另外, TIME_WAIT 状态的等待超时需要再详细解释一下,因为它直接影响到网络应用程序的表现。

       每个具体 TCP 实现必须选择一个报文段最大生存时间 MSL ( Maximum Segment Lifetime ),它是任何报文段被丢弃前在网络内的最长时间。我们知道这个时间是有限的,因为 TCP 报文段以 IP 数据报在网络内传输,而 IP 数据报有限制其生存时间的 TTL 字段。 RFC 793 [Postel 1981c ] 指出 MSL 为 2 分钟。然而,实现中的常用值是 30 秒、 1 分钟、或 2 分钟。

       对一个具体实现所给定的 MSL 值,处理的原则是:当 TCP 执行一个主动关闭,并发回最后一个 ACK ,该连接必须在 TIME_WAIT 状态停留的时间为 2 倍的 MSL ,因此 TIME_WAIT 状态也称为 2MSL 等待状态。在这段时间内,如果最后的 ACK 丢失,对方会超时并重发最后的 FIN ,这样本地 TCP 可以再次发送 ACK 报文段(这也是它唯一可以发送的报文,并重置 2MSL 定时器)。

       这种 2MSL 等待的另一个结果是这个 TCP 连接在 2MSL 等待期间,定义这个连接的套接字( socket ,客户的 IP 地址和端口号,服务器的 IP 地址和端口号)不能再被使用。这个连接只能在 2MSL 结束后才能再被使用。在连接处于 2MSL 等待时,任何迟到的报文段将被丢弃。

       我们假设图 3-12 中是客户执行主动关闭并进入 TIME_WAIT ,这是正常的情况,因为服务器通常执行被动关闭,不会进入 TIME_WAIT 状态。这暗示如果我们终止一个客户程序,并立即重新启动这个客户程序,则这个新客户程序将不能重用相同的本地端口。这不会带来什么问题,因为客户使用本地端口,而并不关心这个端口号是什么。然而,对于服务器,情况就有所不同,因为服务器使用周知端口。如果我们终止一个已经建立连接的服务器程序,并试图立即重新启动这个服务器程序,服务器程序将不能把它的这个周知端口赋值给它的端点,因为那个端口是处于 2MSL 连接的一部分。在重新启动服务器程序前,它需要在 1~4 分钟。这就是很多网络服务器程序被杀死后不能够马上重新启动的原因(错误提示为“ Address already in use ”)。

    3.5 小结

       和 IP 一样, TCP 也是 TCP/IP 协议簇中最为重要的协议。本章详细地介绍了 TCP 的工作原理、数据报格式,特别是 TCP 连接建立与关闭的状态转换。由于 TCP 是离应用层最近的底层协议,因此 TCP 的很多状态在上层应用中是可见的,在后面的章节中,很多地方都涉及到 TCP 的各种状态。因此,掌握本章介绍的原理和概念,对于学好后面的章节极为有利,特别是掌握了 TCP 的状态转换规律,对于网络的配置与诊断、以及网络应用的调试大有裨益。

    展开全文
  • TCP/IP是个协议组,可分为三个层次:网络层、传输层和应用层。  在网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。  在传输层中有TCP协议与UDP协议。  在应用层有:TCP包括FTP、HTTP、TELNET、SMT

    from:http://blog.csdn.net/mengyafei43/article/details/25195445

    TCP/IP 

    TCP/IP是个协议组,可分为三个层次:网络层、传输层和应用层。 
    在网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。 
    在传输层中有TCP协议与UDP协议。 
    在应用层有:TCP包括FTP、HTTP、TELNET、SMTP等协议 
                     UDP包括DNS、TFTP等协议 
    短连接 
    连接->传输数据->关闭连接 
    HTTP是无状态的,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接。 
    也可以这样说:短连接是指SOCKET连接后发送后接收完数据后马上断开连接。 
      
    长连接 
    连接->传输数据->保持连接 -> 传输数据-> 。。。 ->关闭连接。 
    长连接指建立SOCKET连接后不管是否使用都保持连接,但安全性较差。 
      
    http的长连接 
    HTTP也可以建立长连接的,使用Connection:keep-alive,HTTP 1.1默认进行持久连接。HTTP1.1和HTTP1.0相比较而言,最大的区别就是增加了持久连接支持(貌似最新的 http1.0 可以显示的指定 keep-alive),但还是无状态的,或者说是不可以信任的。 
      
    什么时候用长连接,短连接? 
     长连接多用于操作频繁,点对点的通讯,而且连接数不能太多情况,。每个TCP连接都需要三步握手,这需要时间,如果每个操作都是先连接,再操作的话那么处理速度会降低很多,所以每个操作完后都不断开,次处理时直接发送数据包就OK了,不用建立TCP连接。例如:数据库的连接用长连接, 如果用短连接频繁的通信会造成socket错误,而且频繁的socket 创建也是对资源的浪费。 
      
    而像WEB网站的http服务一般都用短链接,因为长连接对于服务端来说会耗费一定的资源,而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源,如果用长连接,而且同时有成千上万的用户,如果每个用户都占用一个连接的话,那可想而知吧。所以并发量大,但每个用户无需频繁操作情况下需用短连好。 
      
    总之,长连接和短连接的选择要视情况而定。 
    发送接收方式 
    1、异步 
    报文发送和接收是分开的,相互独立的,互不影响。这种方式又分两种情况: 
    (1)异步双工:接收和发送在同一个程序中,由两个不同的子进程分别负责发送和接收 
    (2)异步单工:接收和发送是用两个不同的程序来完成。 
    2、同步 
    报文发送和接收是同步进行,既报文发送后等待接收返回报文。 同步方式一般需要考虑超时问题,即报文发出去后不能无限等待,需要设定超时时间,超过该时间发送方不再等待读返回报文,直接通知超时返回。 
      
    在长连接中一般是没有条件能够判断读写什么时候结束,所以必须要加长度报文头。读函数先是读取报文头的长度,再根据这个长度去读相应长度的报文。 

    Socket是什么 

    Socket是应用层与TCP/IP协议族通信的中间软件抽象层,它是一组接口。在设计模式中,Socket其实就是一个门面模式,它把复杂的TCP/IP协议族隐藏在Socket接口后面,对用户来说,一组简单的接口就是全部,让Socket去组织数据,以符合指定的协议。
    \

    通信过程:
    \

    主机 A 的应用程序要能和主机 B 的应用程序通信,必须通过 Socket 建立连接,而建立 Socket 连接必须需要底层 TCP/IP 协议来建立 TCP 连接。建立 TCP 连接需要底层 IP 协议来寻址网络中的主机。我们知道网络层使用的 IP 协议可以帮助我们根据 IP 地址来找到目标主机,但是一台主机上可能运行着多个应用程序,如何才能与指定的应用程序通信就要通过 TCP 或 UPD 的地址也就是端口号来指定。这样就可以通过一个 Socket 实例唯一代表一个主机上的一个应用程序的通信链路了。

    建立通信链路
    当客户端要与服务端通信,客户端首先要创建一个 Socket 实例,操作系统将为这个 Socket 实例分配一个没有被使用的本地端口号,并创建一个包含本地和远程地址和端口号的套接字数据结构,这个数据结构将一直保存在系统中直到这个连接关闭。在创建 Socket 实例的构造函数正确返回之前,将要进行 TCP 的三次握手协议,TCP 握手协议完成后,Socket 实例对象将创建完成,否则将抛出 IOException 错误。
    与之对应的服务端将创建一个 ServerSocket 实例,ServerSocket 创建比较简单只要指定的端口号没有被占用,一般实例创建都会成功,同时操作系统也会为 ServerSocket 实例创建一个底层数据结构,这个数据结构中包含指定监听的端口号和包含监听地址的通配符,通常情况下都是“*”即监听所有地址。之后当调用 accept() 方法时,将进入阻塞状态,等待客户端的请求。当一个新的请求到来时,将为这个连接创建一个新的套接字数据结构,该套接字数据的信息包含的地址和端口信息正是请求源地址和端口。这个新创建的数据结构将会关联到 ServerSocket 实例的一个未完成的连接数据结构列表中,注意这时服务端与之对应的 Socket 实例并没有完成创建,而要等到与客户端的三次握手完成后,这个服务端的 Socket 实例才会返回,并将这个 Socket 实例对应的数据结构从未完成列表中移到已完成列表中。所以 ServerSocket 所关联的列表中每个数据结构,都代表与一个客户端的建立的 TCP 连接。
     
    备注:
    Windows 下单机最大TCP连接数
    调整系统参数来调整单机的最大TCP连接数,Windows 下单机的TCP连接数有多个参数共同决定:
    以下都是通过修改注册表[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip \Parameters]
     
    1.最大TCP连接数      TcpNumConnections
    2.TCP关闭延迟时间    TCPTimedWaitDelay    (30-240)s
    3.最大动态端口数   MaxUserPort  (Default = 5000, Max = 65534) TCP客户端和服务器连接时,客户端必须分配一个动态端口,默认情况下这个动态端口的分配范围为 1024-5000 ,也就是说默认情况下,客户端最多可以同时发起3977 Socket 连接
    4.最大TCB 数量   MaxFreeTcbs
    系统为每个TCP 连接分配一个TCP 控制块(TCP control block or TCB),这个控制块用于缓存TCP连接的一些参数,每个TCB需要分配 0.5 KB的pagepool 和 0.5KB 的Non-pagepool,也就说,每个TCP连接会占用 1KB 的系统内存。
    非Server版本,MaxFreeTcbs 的默认值为1000 (64M 以上物理内存)Server 版本,这个的默认值为 2000。也就是说,默认情况下,Server 版本最多同时可以建立并保持2000个TCP 连接。
    5. 最大TCB Hash table 数量   MaxHashTableSize TCB 是通过Hash table 来管理的。
    这个值指明分配 pagepool 内存的数量,也就是说,如果MaxFreeTcbs = 1000 , 则 pagepool 的内存数量为 500KB那么 MaxHashTableSize 应大于 500 才行。这个数量越大,则Hash table 的冗余度就越高,每次分配和查找 TCP  连接用时就越少。这个值必须是2的幂,且最大为65536.
     
    IBM WebSphere Voice Server 在windows server 2003 下的典型配置
    MaxUserPort = 65534 (Decimal)
    MaxHashTableSize = 65536 (Decimal)
    MaxFreeTcbs = 16000 (Decimal)
    这里我们可以看到 MaxHashTableSize 被配置为比MaxFreeTcbs 大4倍,这样可以大大增加TCP建立的速度

    展开全文
  • TCP/IP是普遍使用的网络互连标准协议,可在不同环境和不同节点之间进行彼此通信,是连入Internet的所有...TCP/IP实际上是种层次型协议,它的内部包含许多其他的协议,组成了TCP/IP协议组,其协议层次表如下:  

       TCP/IP是普遍使用的网络互连标准协议,可在不同环境和不同节点之间进行彼此通信,是连入Internet的所有计算机在网络上进行各种信息交换和传输所必须采用的协议,也是Windows NT、Windows 2000 Server、NetWare及UNIX互连所采用的协议。TCP/IP实际上是一种层次型协议,它的内部包含许多其他的协议,组成了TCP/IP协议组,其协议层次表如下:

                           表1    TCP/IP协议层次

    应 用 层

    HTTP、Telnet、FTP、SMTP、SNMP

    传 输 层

    TCP、UDP

    网 间 网 层

    IP(ARP、RARP、ICMP)

    网络接口层

    Ethernet、X.25、SLIP、PPP

         TCP/IP协议实际上就是在物理网上的一组完整的网络协议,其中TCP是提供传输层服务,而IP则是提供网络层服务。TCP/IP协议的核心部分是传输层协议(TCP、UDP),网络层协议(IP)和物理接口层,这三层通常是在操作系统内核中实现。

     图1 TCP/IP各层次协议

    下面重点介绍传输层中TCP与UDP,及其区别。

    一、用户数据报协议UDP

            用户数据报协议UDP(User Data Protocol)是 OSI 参考模型中一种无连接的传输层协议,提供面向事务的简单、不可靠信息传送服务;UDP 协议基本上是 IP 协议与上层协议的接口;UDP 协议适用端口分别运行在同一台设备上的多个应用程序;它是面向非连接的协议,它不与对方建立连接,而是直接就把数据包发送过去。UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境。比如,我们经常使用“ping”命令来测试两台主机之间TCP/IP通信是否正常,实际ping命令的原理就是向对方主机发送UDP数据包,然后对方主机确认收到数据包,如果数据包到达的消息及时反馈回来,那么网络就是通的。

           UDP数据包中源端口和目标端口字段指定了两个16长的端口号,其中源端口字段是可选的,如果指定了该字段的值,就表示相应的数据包应发往的端口号,如果不使用,应将其设为0。长度字段表示整个UDP数据包的8位字数,包含UDP头部和数据部分。因此,该字段的值最小为8。如图示:

          

    图2   UDP数据报格式

          UDP协议位于IP协议之上,即UDP数据包是封装在IP数据包中进行传输的。 

      UDP头部

            UDP数据区                

     

           IP报头

                    IP报文数据区           

     

                帧头

                                     帧数据区                              

    图3  UDP数据包封装关系

            下面解释一个使用UDP协议的应用程序时如何将数据传输到目的主机A的特定应用程序的。首先接受数据的应用程序要申请一个UDP端口号,设为P。发送方的应用程序准备数据后,将其交给UDP协议,让其将数据发送给主机A的端口P。UDP协议将应用程序的数据作为UDP数据包的数据部分封装在一个UDP数据包中,并将数据包的目标端口字段设置为P。UDP协议再将包交给IP协议处理,让其将该数据包发送到主机A。IP协议将UDP数据包作为IP数据包的的数据封装在一个IP数据包中,并将目的地址设置为A,将协议字段设置为17,然后将其交给网络层处理并发送出去,该IP数据包可能会经过数个路由器,并最终到达主机A的IP协议层。主机A的IP协议发现字段为17,就将IP数据包的数据区交给UDP协议处理。UDP协议发现端口号为P,就将UDP数据包的数据区放置在端口P的队列中。A的应用程序从该队列中将数据取出进行处理。

    二、传输控制协议TCP

            传输控制协议TCP(Transmission  Control  Protocol)是基于连接的协议,即是在正式通信前必须要与对方建立起连接。一个TCP连接必须要经过三次“握手”才能建立起来,这三个简单过程包括主要:主机A向主机B发出连接请求数据包;主机B向主机A发送同意连接和要求同步(同步就是两台主机一个在发送,一个在接收,协调工作)的数据包;主机A再发出一个数据包确认主机B的要求同步。三次“对话”的目的是使数据包的发送和接收同步,经过三次“对话”之后,主机A才向主机B正式发送数据。

            TCP协议向应用程序提供的服务时面向字节流的,TCP数据的传输时通过IP协议进行的,IP协议的传输单位是IP数据包。因为用户提供的字节流数据可能很大,而一个IP数据包所能容纳的数据是有限的,因此TCP协议必须将字节流数据进行分割并组织成IP数据包进行传输,在目标主机的TCP协议将这些分割的数据再组织成数据流。TCP协议数据包有自己的头部和数据包,一个TCP数据包成为段。源端口和目标端口用于指定发送发和接收方的TCP端口号。和UDP协议不同的是,TCP段中源端口号必须指定。这是因为TCP是面向连接的,一个TCP连接由发送方和接收方的IP地址和TCP端口号组成。因为一个TCP端口号可以为不同的链接所中用,所以两个端口号中缺少一个都无法确定该数据段所属的TCP链接,也就无法确定处理数据的应用程序了。下图就是TCP数据段的具体格式:

     

    图4   TCP报文格式

            TCP连接的建立需要进行三次连接信息的发送/接收。三次握手的目的主要是在于同步连接双方发送数据的初始序列号。首先,连接的主动打开方式(即连接请求方)向被动打开方(即连接接受方)发送一个TCP数据段,该TCP段通常不包含数据区,并将代码位中SYN位置1设在序列号字段设置一个初始序列号。被动打开方接收到这个链接请求段后,向主动打开方发送一个TCP段。将ACK位置1,表示已经收到了主动打开方的连接请求。被动打开还会将SYN位置1并在序列号字段设置自己的初始序列号。主动打开方收到被动打开方的TCP段之后会发送一个ACK给被动打开方,接收方收到该数据段后连接的建立就完成了,就可以开始传输数据了。

    图5  TCP建立连接的三次握手过程

    三、TCP与UDP的比较

            因为UDP协议无连接,所以它的通信效率高;也正因如此,它的可靠性不如TCP协议高。

           TCP提供的是可靠的传输服务,而UDP协议提供的是不可靠的服务。UDP协议没有流量控制机制,如果发送进程发送数据报塞满了接收进程的接收缓冲区,就会丢弃数据报,而出现这种情况,UDP协议不会通知发送进程减缓数据的发送速率。TCP协议则拥有流量控制,具体机制暂略。

     

           TCP提供的是面向字节流的服务。应用程序只需将要传输的数据以字节流的形式提交给TCP协议,在连接的另一段,数据以同样的字节流顺序出现在接收程序中。而UDP协议的传输单位是数据块,一个数据块只能封装在一个UDP数据包中。

           TCP不适用于只有少量数据传输的情况,因为连接的开销较大,这么做得不偿失;此外TCP也不适用于实时应用,因为TCP协议对数据的传输是有先后顺序的,只有前面的传输成功才会开始后面的数据传送,这显然不符合实时应用的要求。

            对于不适合使用TCP协议的应用就只能使用UDP协议,使用UDP协议进行通信时应用程序必须自己处理下列问题:(1)应用程序必须自己提供机制来保证可靠性。应用程序必须有自己的超时重发机制、数据失序的处理、流量控制等。当然对于一些可靠性要求不高的应用可以不用这些机制,但通常都需要区分数据的先后关系。(2)应用程序必须处理大块数据的分割,以让其能封装在一个UDP数据包中。在接收方还必须再将分割的数据进行重组。

           UDP协议中,发送进程在发送每个数据报的时候并不等待多个数据报集中在一起以一个较大数据报发送出去,而是立即发送出去,它是记录型的协议。并且接收进程每次通过read或recv获得的数据报必定是发送进程所发送的那个数据报,不可能是多个数据报,接收进程可以识别到发送进程所发送的每个数据报的记录边界;TCP协议中发送进程在发送每个数据报的时候在内核处理过程中有可能并不立即发送出去,而是会将多个数据报集中在一起以一个较大的数据报来发送,它是字节流的协议。而接收进程每次通过read来读取发送进程发送过来的数据报并不一定是发送进程原先发送数据报,接收进程无法识别每个数据报的记录边界,所以TCP协议就是字节流的、无记录边界的协议。如QQ聊天所用到的协议就应该是有记录边界的,聊天过程中是以“消息”为单位,消息可以看成一个记录,所以QQ聊天协议采取UDP协议而不是TCP协议。

          UDP协议是无序的传输协议。发送进程所发送的每个数据报并不按照原先发送的顺序到达接收进程,有可能早发送的数据报较后到达接收进程,因为数据报在经过中间路径的传送时会因为各个数据报传送的路径不同或者其它原因而造成这些数据报到达的顺序不同,为了使基于UDP协议的应用程序有序,必须在应用程序中设置序号、确认机制来使其有序,TFTP协议是基于UDP的协议;TCP协议是有序协议,有超时、序号、重传、确认机制。如FTP协议是基于TCP用于传送文件的协议,FTP协议中的控制连接传送的内容都是基于消息形式,客户端在控制连接上发出一个请求消息,服务器端返回一个请求结果消息,因为控制连接上是交互式的消息传送,客户端在发送一个请求之后,在服务器端的响应消息未到达之前,客户端是不会发送第二个请求消息的,所以对于交互式的消息传递采用TCP协议使我们不必担心两个请求消息会叠加在一起。

          UDP协议在创建插口之后,可以同多个服务器端建立通信,而TCP协议只能与一个服务器端建立通信,TCP不允许目的地址是广播或多播地址,而UDP允许;UDP协议客户端同服务器端的通信关系可以是一对多的关系,而TCP协议只能是一对一的关系。

    表2:客户端连接过程

    表3:服务器端连接过程

    展开全文
  • 传输层协议TCP&UDP

    千次阅读 2009-06-24 16:17:00
    传输层协议TCP&UDP(2009-01-18 12:18:37)标签:tcp udp 传输控制协议(Transmission Control Protocol, TCP)是种面向连接(连接导向)的、可靠的、基于字节流的运输层(Transport layer)通信协议,由IETF的RFC...
  • 首先注意,传输层只针对于网络层是IP协议的传输通道而言的,比如自定义以太网类型的以太网报文、ARP报文都不需要传输层。 网络层实现了网络中每个主机(节点)之间的报文送达,但真正使用这些报文的是每个主机的个...
  • UDP协议 UDP协议端格式: 16位UDP长度, 表示整个数据报(UDP首部+UDP数据)的最大长度; 如果校验和出错, 就会直接丢弃... 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用返回任何错误信息; 面向数据报: ...
  • 简单理解TCP/IP传输层协议TCP和UDP

    千次阅读 2019-08-13 12:33:46
    TCP/IP模型的传输层主要协议有TCP (Transmission Control Protocol,传输控制协议)和UDP(User Data Protocol,用户数据报协议)。 比如:应用程序A和 B 利用TCP通信: TCP 把A的数据分成多个段,把段传送给网络...
  • 尽管它可能在传输中检查数据是否被破坏,但是它并不要求发送端重传被破坏或丢失的数据。对于某些应用,UDP有个优势,即它是面向报文的,它保留报文边界。 要理解UDP,可以将无连接、不可靠的服务与邮局提供的常规...
  • 博文目录、传输层与传输层协议 二、用户数据报协议(UDP) 三、传输控制协议TCP 四、TCP协议滑动窗口、传输层与传输层协议1. 传输层的基本功能 传输层的本质就是为分布在不同地理位置的计算机的进程通信提供...
  • 我们在传输数据时,可以只用到(传输层)TCP/IP协议,但是没有应用层只用传输层的话,便无法识别数据内容,如果...WEB使用HTTP协议作应用层协议,以封装HTTP文本信息,然后使用TCP/IP做传输层协议将它发到网络上。
  • 通过本实验,熟悉PacketTracer的使用,学习PacketTracer中仿真分析应用层和传输层协议,加深对协议工作过程的理解。 实验内容 从PC使用URL捕获Web请求,运行模拟并捕获通信,研究捕获的通信。 Wireshark 可以...
  • 传输层学习之传输层,UDP)

    千次阅读 2013-08-12 21:10:56
    传输层协议为运行在不同主机上的应用之间提供了逻辑通信功能,而网络层则是提供了主机之间的逻辑通信服务。。传输层运行在主机上即端系统上。其基本通信过程为 发送方:传输层接收到来自应用进程的报文,并将其...
  • 传输层安全协议TLS/SSL

    千次阅读 2016-08-29 18:14:06
    部分链接可能需要使用Google才能打开描述:传输层安全协议TLS(Transport Layer Security)是设计用来保护网络通信过程中信息的私密性的种工业标准,允许客户机,服务器应用程序可以探测到安全风险,包括消息篡改...
  • 层协议(5层) 物理层、数据链路层、网络层、传输层、应用层 五层结构的概述 应用层:通过应用进程间的交互来完成特定网络应用 数据:报文 协议:HTTP, SMTP(邮件), FTP(文件传送) 运输层:向两个主机进程之间的...
  • HTTP 2.0的最大改进我觉得有两点:第:新增了帧的好处在于重新分发流信息,服务器处理顺序可以不再依赖用户提交请求的顺序了。另外就是不必一定用TCP传输HTTP了,实际上规范开始就是这么说的。第二:HTTP...
  • OSI七层协议大白话解读

    万次阅读 多人点赞 2018-08-02 16:59:48
    互联网的本质就是系列的网络协议,这个协议就叫OSI协议系列协议),按照功能不同,分工不同,人为的分层七层。...七层划分为:应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。 五层...
  • 信号的传输总要符合一定的协议(protocol)。比如说长城上放狼烟,是因为人们已经预先设定好狼烟这个物理信号代表了“敌人入侵”这抽象信号。这样个“狼烟=敌人入侵”就是个简单的协议协议可以更复杂,比如...
  • 网络协议概述:物理层、连接层、网络层、传输层、应用层详解 这篇文章主要介绍了网络协议概述:物理层、连接层、网络层、传输层、应用层详解,本文用生活中的邮差与邮局来帮助理解复杂的网络协议,通俗...
  • OSI七层协议在网络传输中扮演的角色及功能:7、应用层——–电脑的各种数据6、表示层 ——– 处理用户信息的表示问题,如编码、数据格式转换和加密解密5、会话层——–会话管理、会话流量控制、寻址、寻址4、传输层...
  • SSL&TLS传输层加密协议实现图解

    千次阅读 2017-09-27 23:03:11
    、SSL&TLS  1.SSL:Secure ... Sockets Layer ,加密套接字协议层 ... 1)SSL是为网络通信提供安全及数据完整性的种安全协议,在传输层对网络连接进行加密  Secure Socket Lay
  • OSI七层模型详解(物理层、数据链路层、网络层、传输层.....应用层协议与硬件)   OSI 七层模型通过七个层次化的结构模型使不同的系统不同的网络之间实现可靠的通讯,因此其最主要的功能就是帮助...
  • 传输层: 选择重传协议

    万次阅读 2013-12-21 22:06:57
    但是如果低下的网络层协议丢失了很多分组,那么返回N协议的效率就会很低.每当个分组损坏,发送方就需要重传所有待确认的分组,虽然其中有些分组实际上已经完好地 被接收了. 选择重传协议(Selective-Repeat, S
  • http层协议层通信协议

    万次阅读 2020-01-19 10:54:47
    OSI 和 TCP/IP通信协议对比 如图 HTTP协议处于TCP/IP协议体系的应用。HPPT协议属于应用协议,因此工作在最高层,即应用。图中未标记出HTTP协议,它与FTP、DNS等协议工作 在同一...文件传输协议(FTP,Fi...
  • IP协议号与传输层端口

    千次阅读 2009-12-04 13:50:00
    比如在传输层如果是tcp连接,那么在网络层ip包里面的协议号就将会有个值是6,如果是udp的话那个值就是17-----传输层传输层--通过接口关联(端口的字段叫做端口)---应用层 协议号是存在于IP数据报的首部的20字节的...
  • 端口号是传输层协议的内容。 端口号是个2字节16位的整数; 端口号用来标识网络进程,告诉操作系统,当前的这个数据要交给哪一个进程来处理; IP地址+端口号能够标识网络上的某台主机的某个进程; 个...
  • 传输层详解

    万次阅读 2016-01-06 19:08:05
    传输层详解 ①理解TCP的封装和工作原理 ②理解UDP的封装和工作原理 ③了解常用的TCP和UDP端口号 ④对TCP和UDP首部能够进行分析   传输层的作用是什么?传输层实现端到端的连接,端到端是什么概念呢?打个...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 205,940
精华内容 82,376
关键字:

哪一组是传输层协议