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

    千次阅读 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不保证。

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

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

    展开全文
  • 传输层协议、应用层协议

    千次阅读 2018-05-10 00:17:10
    传输层协议、应用层协议一、传输层协议1、传输层概述 (1)传输层的作用 IP层提供点到点的连接 传输层提供端到端的连接 (2)传输层的协议 TCP(Transmission Control Protocol)传输控制协议 可靠的、面向...

    传输层协议、应用层协议

    一、传输层协议

    1、传输层概述

        1)传输层的作用

                 IP层提供点到点的连接

                 传输层提供端到端的连接

        2)传输层的协议

             TCP(Transmission Control Protocol)传输控制协议

              可靠的、面向连接的协议;传输效率低

             UDP(User Datagram Protocol)用户数据报协议

              不可靠的、无连接的服务

              传输效率高

    2、TCP协议 (可靠地)          

    0 -- 1023 为常用端口号,已经被占用了,自定义端口号选1024以上,最大值是65535。

    1)TCP 的封装格式

     

    2)TCP的连接与断开

    TCP的连接 ---- 三次握手                    


    TCP的断开 ---- 四次握手

    3)TCP的流控与差错控制

         TCP的流控机制 -- 滑动窗口

         TCP的流控机制 -- 拥塞控制

         TCP差错控制的三种方式

         -- 校验和

         -- 确认

         -- 超时

    4)TCP的计时器

        ① TCP的重传计时器 -- 为了控制丢失的数据段

        ② TCP的坚持计时器 -- 为了防止零窗口死锁

        ③ TCP的保活计时器 -- 防止两个TCP连接之间长时间的空闲

        ④ TCP的时间等待计时器 -- 连接终止期间使用,当发送了最后一个ACK后,不立即关闭连接,

                                  而是等待一段时间,保证能接收到重复的FIN数据段。

    5)TCP的应用

    端口号

    协议

    作用

    21

    FTP

    文件传输协议,用于文件上传和下载

    23

    Telnet

    用于远程登录,通过连接目标计算机的这一端口,

    得到验证后,可以远程控制管理目标计算机

    25

    SMTP

    简单邮件传输协议,用于发送邮件

    53

    DNS

    域名服务,当用户输入网站名称后,由DNS负责将他解析成IP地址

    80

    HTTP

    超文本传输协议,通过HTTP实现网络上超文本的传输

    3、UDP协议

    1)UDP的封装格式

     

          2)UDP的应用

    端口号

    协议

    说明

    53

    DNS

    域名服务

    69

    TFTP

    简单文件传输协议

    123

    NTP

    网络时间协议

    111

    RPC

    远程过程调用

    3)UDP的流控与差错控制

         UDP没有流控机制

         UDP只有校验和来提供差错控制

          --- 需要上层协议来来提供差错控制:例如TFTP协议

     

    二、应用层概述

       1、应用层的作用

           与应用程序协同工作,利用基础网络交换应用程序专用的数据

       2、常见的应用层协议

           --- DNS

           --- SMTP和POP3

           --- HTTP和HTTPS

           --- Telnet

           --- FTP和TFTP

    三、应用层协议精讲

       1、DNS(Domain Name System)域名系统

           作用:用来完成域名与IP地址之间的映射

           端口号:TCP或UDP的53号端口

           分布式、层次性

           域名空间结构

            -- 根域

            -- 顶级域

            -- 二级域名

            FQDN = 主机名 + .DNS后缀

            通用域

            

       2、SMTP与POP3

           --- SMTP(Simple Mail Transfer Protocol)简单邮件传输协议

               作用:用于发送和接收邮件

               端口号是25号

           --- POP3(Post Office Protocol V3)邮局协议版本3

               作用:用于客户端接收邮件

               端口号是110

       3、HTTP与HTTPS

           --- HTTP(Hyper Text Transfer Protocol)超文本传输协议

               作用:用于传输Internet浏览器使用的普通版本、超文本、音频和视频等数据

               端口号为TCP的80

           --- HTTPS安全超文本传输协议

               作用:基于HTTP开发,提供加密,可以确保消息的私有性和完整性

                     端口号为443

       4、FTP和TFTP

           --- FTP(File Transfer Protocol)文件传输协议

                使用最为广泛的文件传输应用

    端口号为TCP的20端口和21端口

           --- TFTP(Trivial File Transfer Protocol)简单文件传输协议

               用来传输一些琐碎的小文件

               端口号为UDP的69号端口

       5、FTP的工作原理

           -- 控制连接:TCP 21,用于发送FTP命令信息

           -- 数据连接:TCP 20,用于上传、下载数据

           -- 数据连接的建立类型:主动模式和被动模式

       6、TFTP的工作原理

           -- 数据传输是在连接建立和终止之间发生的

           -- 文件划分成若干个数据块

                   每一块为512个字节

                   最后一块必须在0 -- 511之间

           -- 文件传输的可靠性保证

                    TFTP自行提供流控和差错控制

       7、Telnet(Terminal Network)终端网络应用

            通过文本方式远程管理计算机或路由器/交换机

            端口号为TCP的23

       8、Telnet配置命令

      

     

     

     

     

     

     

            

    展开全文
  • 15-传输层协议和应用层协议

    千次阅读 2018-04-28 09:49:32
       PS:针对上一篇tcp协议中说到的端到端服务,这里我们再通过传输层协议和应用层协议之间的关系来加深端到端服务的学习和理解。 1. 传输层协议和应用层层协议的关系   在应用层,我们知道有很多协议,比如...

       PS:针对上一篇tcp协议中说到的端到端服务,这里我们再通过传输层协议和应用层协议之间的关系来加深端到端服务的学习和理解。


    1. 传输层协议和应用层层协议的关系

      在应用层,我们知道有很多协议,比如常见的有http,tfp,telnet等,传输层常见的协议有tcp,udp等。通常在发送数据时,应用层是怎么来把数据发送给指定传输层的协议?而在接收数据时,传输层又是怎么把数据上交给指定的应用层协议来处理的?

      带着这几个问题,我们思考一下传输层的协议是怎么来区分应用层的协议呢?

      通常传输层协议为应用层的每一个协议标识了一个端口号,也就是传输层通过不同的端口号来区分不同的应用层协议,传输层协议和应用层协议之间的关系,如图1所示:

    这里写图片描述
    图1-传输层协议和应用层协议之间的关系

      从图1中不难看出,传输层加了端口号来标识应用层的每个协议,那么我们可以知道传输层协议和传输层协议之间的关系:

    1.HTTP协议默认使用了TCP的80端口号
    2.FTP协议默认使用TCP的21端口号
    3.TELNET协议默认使用了TCP的23端口号
    4.SMTP协议默认使用了TCP的25端口号
    5.DNS协议默认使用了UDP的53端口号
    6.RIP协议默认使用了UDP的520端口号
    7.DHCP协议默认使用了UDP的67端口号

      一般来说这些默认端口号是熟知端口(0 - 1023),由IANA组织已经分配好的,最好不要随意改动,以免出现端口不可用或被占用,造成网络无法通信的情况。

    这里写图片描述
    图2-端口和服务的关系

      在图2中可以看到,服务器上运行了web服务,smtp服务,pop3服务,这三个服务分别使用了不同的协议和服务端端口号与客户端进行通信,另外这三台计算机分别也使用了不同客户端端口号和服务端通信。现在这三台计算机分别要访问服务器上的不同服务,发送了3个数据包。

      A计算机要访问服务器上的web服务,因为服务器上的web服务使用了http协议和80端口跟客户端进行通信,所以A计算机发送的数据包,必须封装服务器的目标地址和服务对应的目标端口号,同时服务器也要通过这个数据包拿到源地址和源端口号,然后和客户端通信,因此我们会看到数据包中封装的这些信息。

      对于B计算机和C计算机都是同理,当服务器收到这三个数据包,会根据数据包中不同的目标端口号交给不同的服务,然后服务器上的服务会根据数据包中不同的源端口号再把数据返回给不同的计算机。

      现在我们基本上明白了,ip地址是用来定位网络上的某一台服务器,而端口号是用来定位服务器上的某一个服务。到这里,相信你对端到端服务有更深的理解了。


    2. 传输层协议和网络层协议的区别

    这里写图片描述
    图3-传输层协议和网络层协议的区别

      简单来说,传输层协议主要用于主机的进程与进程之间的相互通信,而网络层协议主要应用于主机与主机之间的相互通信。


    3. 套接字地址

    这里写图片描述
    图4-套接字地址

      实际上TCP使用“连接”(不仅仅是端口)作为最基本的抽象,同时将TCP连接的端点称为插口,或套接字(socket)。

      前面我们说过TCP协议是通过IP地址+端口号的形式来确定数据发送的目标主机的目标进程。那么套接字和端口,IP地址的关系就是:套接字其实就是IP地址和端口号,比如在网络编程里用套接字来表示ip地址和端口号。


    4. 关于字节号和序号

      不知道大家还有没有印象,之前我们在14-tcp协议中的第三小节(TCP对数据封装过程)简单提到过字节和序号,如果有小伙伴不太理解的话,这里再详细介绍一下字节号和序号。

      字节号:TCP是面向字节流的,因此TCP会对字节数据进行编号,即每一个字节数据都会有一个编号,这个编号就叫字节号,编号的范围是:0 ~ 2^32-1,需要注意的是TCP对字节数据编号不是从0和1开始的,而是根据系统内核机制来随机编号的。

    举个栗子:
      现在主机A随机产生了一个编号为1024的字节号,如果现在主机A要发送一个数据,该数据为6000字节大小,那么该数据的字节号范围为1024 - 7023。

      序号:前面我们说过序号是针对数据段的,由主机发送的这6000字节数据以数据段为单位,封装成多个大小不同的tcp数据段报文在网络中传输。因为序号是基于字节号的,所以tcp协议会给每个tcp数据段报文分配一个序号,而这个序号就是tcp数据段报文的第一个字节的编号(字节号)。

    举个栗子:
      比如现在主机A要发送一个6000字节大小的数据,tcp协议对数据分成5个数据段报文来发送,前4个数据段报文都是1000字节,最后一个报文是2000字节。

    假如第一个字节的编号为110
    那么第一个报文的字节号范围:110 ~ 1109
    第二个报文的字节号范围:1110 ~ 2109
    第三个报文的字节号范围:2110 ~ 3109
    第四个报文的字节号范围:3110 ~ 4109
    第五个报文的字节号范围:4110 - 6109
    到这里,序号已经间接给出来了

    展开全文
  • 因特网传输层协议

    千次阅读 2016-08-29 10:14:09
    尽管因特网使用很多传输层协议,但是我们在本章只讨论两个,如图3-38所示。 图3-38中给出了UDP和TCP这两个传输层协议与其他协议的关系,以及TCP/IP协议簇的层次。这些协议位于应用层和网络层之间,是应用程序和网络...
    尽管因特网使用很多传输层协议,但是我们在本章只讨论两个,如图3-38所示。
    

    图3-38中给出了UDP和TCP这两个传输层协议与其他协议的关系,以及TCP/IP协议簇的层次。这些协议位于应用层和网络层之间,是应用程序和网络操作的中间媒介。

    UDP是不可靠的无连接传输层协议,由于在应用中简单高效而被使用,在那些应用中差错控制由应用层进程提供。TCP是可靠的面向连接协议,可用于可靠性重要的任何应用。

     
    (点击查看大图)图3-38  在TCP/IP协议簇中传输层协议的位置

    如前所述,传输层协议通常有很多责任。一个是创建进程到进程通信;这些协议使用端口号来完成这项责任(见表3-1)。

    表3-1  UDP和TCP使用的熟知端口


    展开全文
  • 5G云计算:传输层协议介绍

    千次阅读 2020-06-17 11:26:19
    传输层协议介绍TCP协议介绍TCP/IP协议族的传输层协议TCP报文段TCP链接TCP建立链接的过程称为3次握手![在这里插入图片描述](https://img-blog.csdnimg.cn/20200617110758200.png?x-oss-process=image/watermark,type_...
  • 网络层协议和传输层协议

    千次阅读 2017-04-27 10:42:30
    应用层协议: 1、远程登录协议(Telnet) 2、文件传输协议(FTP) 3、超文本传输协议(HTTP) 4、域名服务协议(DNS) 5、简单邮件传输协议(SMTP) 6、邮局协议(POP3)   其中,从网络上...
  • 传输层协议TCP与UDP的区别

    千次阅读 2018-01-06 19:16:20
    TCP协议与UDP协议作为传输层最常用的两种传输协议,这两种协议都是使用...快递小哥通过地址将包裹送到指定的收货地址,传输层协议的作用也类似,它们把我们需要接收的数据按照传输层协议中的地址信息发送到我们的主机上
  • SOME/IP的传输层协议

    千次阅读 2019-11-01 14:11:49
    SOME/IP的传输层协议 SOME/IP shall be transported using UDP and TCP based on the configuration. When used in a vehicle the ports used shall be specified in the Interface Specification. 根据配置使用...
  • 4.2 无线传感器网络传输层协议

    千次阅读 2020-06-10 14:51:30
    无线传感器网络传输层协议 作业 解释 UDP 和 TCP 不适合无线传感器网络的原因。 UDP: UDP 采用的是无连接的传输, 虽然能够保证网络的实时性,时延非常小,但其数据丢包率较高,不能保证数据可靠传输,因而不适用...
  • Thrift源码解析(三)传输层协议

    千次阅读 2017-06-21 14:53:15
    传输层协议解析概述Thrift源码解析(二)序列化协议一文中介绍了thrift中传输的数据流怎么序列化,本文介绍数据流怎么传输。如 Thrift源码解析(一)主要类概述一文中的类继承图所示,thrift中所有的传输层协议的基类是...
  • 应用层协议和传输层协议之间的关系HTTP=TCP+80FTP=TCP+21HTTPS=TCP+443SMTP=TCP+25POP3=TCP+110RDP=TCP+3389远程桌面DNS=UDP+53或TCP+53Windows共享文件夹=TCP+445SQL=TCP+1433TELNET=TCP+23 转载于:...
  • 计算机网络:传输层协议TCP详解

    千次阅读 2019-06-17 01:47:10
    TCP协议作为传输层协议,它在网络层IP协议不可靠的尽力而为服务至上提供了一个可靠数据传输服务。TCP协议的数据传输确保了其上层协议读出的数据是无损坏、无间隔、按序、非冗余的二进制流。 TCP是面向连接的,在两个...
  • TLS安全传输层协议

    千次阅读 2012-01-06 14:05:36
    TLS:安全传输层协议  TLS:Transport Layer Security概况  安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS ...
  • 实验四 应用层和传输层协议分析(PacketTracer) 一、实验目的:  通过本实验,熟悉PacketTracer的使用,学习在PacketTracer中仿真分析应用层和传输层协议,进一步加深对协议工作过程的理解。 二、实验内容...
  • 一、实验目的: 通过本实验,熟悉PacketTracer的使用,学习在PacketTracer中仿真分析应用层和传输层协议,进一步加深对协议工作过程的理解。二、实验内容: 研究应用层和传输层协议 从 PC 使用 URL 捕获 Web 请求...
  • 应用程序开发者对于传输层的控制仅限于:选择传输层协议、也许能设定几个传输层参数,如最大缓存和最大报文段长度。一旦应用程序开发者选择了一个传输层协议,则应用程序就建立在由该协议提供的传输层服务之上。 2 ...
  • Internet 传输层协议

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

    千次阅读 2019-07-03 20:52:07
    ISO10681-2定义了一种在连接到FlexRay网络的节点之间传输大块数据的方法,TP层分段消息最多一次可以传输64KB-1,即65535个字节,常用于FlexRay ECU诊断和软件刷写,本文带大家深度剖析FlexRay传输层协议ISO10681-2和...
  • 传输层协议(TCP/UDP)概述

    千次阅读 2019-01-15 19:46:56
    源IP地址+源端口号+目标IP地址+目标端口号+传输层协议 IP地址:用来在网络上标识唯一的主机 用uint32_t(43亿)的数据表示 端口号:用来标识一台主机上进行网络通信的进程 用uint_16的数据表示 通过五元组标识后...
  • 通过本实验,熟悉PacketTracer的使用,学习PacketTracer中仿真分析应用层和传输层协议,加深对协议工作过程的理解。 实验内容 从PC使用URL捕获Web请求,运行模拟并捕获通信,研究捕获的通信。 Wireshark 可以...
  • UNIX网络编程笔记(1)—传输层协议

    千次阅读 2016-05-17 11:25:46
    UNIX网络编程,传输层协议简介
  • 稍后更新。。。这应该是国内讲解协议最好的老师了。。。 转载于:https://www.cnblogs.com/Chamberlain/p/10548140.html
  • TLS安全传输层协议(加密)配置文档 Tomcat服务器配置https双向认证(使用keytool生成证书) 一,HTTPS原理 1,HTTP、HTTPS、SSL、TLS介绍与相互关系   (1)HTTP:平时浏览网页时候使用的一种协议。HTTP协议...
  • 计算机网络——传输层协议

    千次阅读 2017-05-08 14:56:48
    需要掌握的知识点有: 多路复用和多路分解 UDP用户数据报协议2.1 广播和多播 2.2 IGMP:Internet组管理协议 TCP传输控制协议3.1 对TCP报文结构各个字段的解释 ...参考资料传输层传输层架构在网络层提
  • TCP:Transmission Control Protocol 传输控制协议TCP是一种面向连接(连接导向)的、可靠的、基于字节流的运输层(Transport layer)通信协议,由IETF的...参考模型中一种无连接的传输层协议,提供面向事务的简单不可
  • 网络传输层协议tcp和udp协议的区别

    千次阅读 2018-05-02 22:43:45
    1. tcp: 传输控制协议,全拼:Transmission Control Protocol 它是一个面向连接,可靠的传输协议2.... tcp和udp都是传输层的两个传输协议4. tcp的特点: 4.1 面向连接,间接验证对方ip的有效性 4.2 可靠的传输 ...
  • 为了解决安全问题,只要使用安全传输层协议(TLS)进行传输并使用CA认证即可。 制作证书及秘钥 我们需要使用OpenSSL制作CA机构证书、服务端证书和客户端证书,以下操作均在安装Docker的Linux服务器上进行。 创建...
  • ssh传输层协议

    千次阅读 2018-01-24 19:13:45
    环境纯理论知识,只是笔记,非教程二进制协议格式每个数据包为以下格式: 类型 名称 uint32 packet_length byte padding_length byte[n1] payload; n1=packet_length-padding_length-1 byte[n2] random ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 56,434
精华内容 22,573
关键字:

传输层协议