网络原理之传输层与网络层重点协议 |
您所在的位置:网站首页 › 常用的基于udp协议的应用有 › 网络原理之传输层与网络层重点协议 |
目录 传输层重点协议 TCP协议 TCP协议段格式 TCP原理 确认应答机制(安全机制) 超时重传机制(安全机制) 连接管理机制(安全机制) 滑动窗口(效率机制) 流量控制(安全机制) 拥塞控制(安全机制) 延迟应答(效率机制) 捎带应答(效率机制) 其他特性:面向字节流、缓冲区、大小限制 粘包问题 TCP异常情况 TCP小结 基于TCP应用层协议 UDP协议 UDP协议端格式 UDP的特点 无连接 不可靠 面向数据报 缓冲区 大小受限 TCP/UDP对比 网络层重点协议 IP协议 传输层重点协议负责数据能够从发送端传输接收端。 TCP协议TCP,即Transmission Control Protocol,传输控制协议。人如其名,要对数据的传输进行一个详细的 控制。 TCP协议段格式TCP对数据传输提供的管控机制,主要体现在两个方面:安全和效率。 这些机制和多线程的设计原则类似:保证数据传输安全的前提下,尽可能的提高传输效率。 确认应答机制(安全机制)TCP将每个字节的数据都进行了编号。即为序列号。 每一个ACK都带有对应的确认序列号,意思是告诉发送者,我已经收到了哪些数据;下一次你从哪里开始发。 超时重传机制(安全机制)但是,主机A未收到B发来的确认应答,也可能是因为ACK丢失了; 因此主机B会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包,并且把重复的丢弃 掉。 这时候我们可以利用前面提到的序列号,就可以很容易做到去重的效果。 那么,如果超时的时间如何确定? 最理想的情况下,找到一个最小的时间,保证 "确认应答一定能在这个时间内返回"。但是这个时间的长短,随着网络环境的不同,是有差异的。如果超时时间设的太长,会影响整体的重传效率;如果超时时间设的太短,有可能会频繁发送重复的包;TCP为了保证无论在任何环境下都能比较高性能的通信,因此会动态计算这个最大超时时间。 Linux中(BSD Unix和Windows也是如此),超时以500ms为一个单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍。如果重发一次之后,仍然得不到应答,等待 2*500ms 后再进行重传。如果仍然得不到应答,等待 4*500ms 进行重传。依次类推,以指数形式递增。累计到一定的重传次数,TCP认为网络或者对端主机出现异常,强制关闭连接。 连接管理机制(安全机制)在正常情况下,TCP要经过三次握手建立连接,四次挥手断开连接 服务端状态转化: [CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态,等待客户端连接;[LISTEN -> SYN_RCVD] 一旦监听到连接请求(同步报文段),就将该连接放入内核等待队列中,并向客户端发送SYN确认报文。[SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文,就进入ESTABLISHED状态,可以进行读写数据了。[ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接(调用close),服务器会收到结束 报文段,服务器返回确认报文段并进入CLOSE_WAIT;[CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据);当服务器真正调用close关闭连接时,会向客户端发送FIN,此时服务器进入 LAST_ACK状态,等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)[LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK,彻底关闭连接。客户端状态转化: [CLOSED -> SYN_SENT] 客户端调用connect,发送同步报文段;[SYN_SENT -> ESTABLISHED] connect调用成功,则进入ESTABLISHED状态,开始读写数据;[ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时,向服务器发送结束报文段,同时进 入FIN_WAIT_1;[FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认,则进入FIN_WAIT_2, 开始等待服务器的结束报文段;[FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段,进入TIME_WAIT,并发 出LAST_ACK;[TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life,报文最大生存时 间)的时间,才会进入CLOSED状态。下图是TCP状态转换的一个汇总: 关于 "半关闭" ,男女朋友分手例子 TIME_WAIT MSL是TCP报文的最大生存时间,因此TIME_WAIT持续存在2MSL的话,就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启,可能会收到来自上一个进程的迟到的数据,但是这种数据很可能是错误的);同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失,那么服务器会再重 发一个FIN。这时虽然客户端的进程不在了,但是TCP连接还在,仍然可以重发 LAST_ACK);CLOSE_WAIT 一般而言,对于服务器上出现大量的 CLOSE_WAIT 状态,原因就是服务器没有正确的关闭 socket,导致四次挥手没有正确完成。这是一个 BUG。只需要加上对应的 close 即可解决问题。 滑动窗口(效率机制)刚才我们讨论了确认应答策略,对每一个发送的数据段,都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点,就是性能较差。尤其是数据往返的时间较长的时候。 既然这样一发一收的方式性能较低,那么我们一次发送多条数据,就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)。 那么如果出现了丢包,如何进行重传?这里分两种情况讨论。 情况一:数据包已经抵达,ACK被丢了。 这种情况下,部分ACK丢了并不要紧,因为可以通过后续的ACK进行确认; 情况二:数据包就直接丢了。 这种机制被称为 "高速重发控制"(也叫 "快重传")。 流量控制(安全机制)接收端处理数据的速度是有限的。如果发送端发的太快,导致接收端的缓冲区被打满,这个时候如果发送端继续发送,就会造成丢包,继而引起丢包重传等等一系列连锁反应。 因此TCP支持根据接收端的处理能力,来决定发送端的发送速度。这个机制就叫做流量控制(Flow Control); 接收端将自己可以接收的缓冲区大小放入TCP 首部中的 "窗口大小" 字段,通过ACK端通知发 送端;窗口大小字段越大,说明网络的吞吐量越高;接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值通知给发送端;发送端接受到这个窗口之后,就会减慢自己的发送速度;如果接收端缓冲区满了,就会将窗口置为0;这时发送方不再发送数据,但是需要定期发送一 个窗口探测数据段,使接收端把窗口大小告诉发送端。接收端如何把窗口大小告诉发送端呢?回忆我们的TCP首部中,有一个16位窗口字段,就是存放了窗口大小信息; 那么问题来了,16位数字最大表示65535,那么TCP窗口最大就是65535字节么? 实际上,TCP首部40字节选项中还包含了一个窗口扩大因子M,实际窗口大小是 窗口字段的值左移 M 位; 拥塞控制(安全机制)虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题。 因为网络上有很多的计算机,可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下,贸然发送大量的数据,是很有可能引起雪上加霜的。 TCP引入 慢启动 机制,先发少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据; 像上面这样的拥塞窗口增长速度,是指数级别的。"慢启动" 只是指初使时慢,但是增长速度非常快。 为了不增长的那么快,因此不能使拥塞窗口单纯的加倍。此处引入一个叫做慢启动的阈值当拥塞窗口超过这个阈值的时候,不再按照指数方式增长,而是按照线性方式增长少量的丢包,我们仅仅是触发超时重传;大量的丢包,我们就认为网络拥塞; 当TCP通信开始后,网络吞吐量会逐渐上升;随着网络发生拥堵,吞吐量会立刻下降; 拥塞控制,归根结底是TCP协议想尽可能快的把数据传输给对方,但是又要避免给网络造成太大压力的 折中方案。 TCP拥塞控制这样的过程,就好像 热恋的感觉 延迟应答(效率机制)如果接收数据的主机立刻返回ACK应答,这时候返回的窗口可能比较小。 假设接收端缓冲区为1M。一次收到了500K的数据;如果立刻应答,返回的窗口就是500K;但实际上可能处理端处理的速度很快,10ms之内就把500K数据从缓冲区消费掉了;在这种情况下,接收端处理还远没有达到自己的极限,即使窗口再放大一些,也能处理过 来;如果接收端稍微等一会再应答,比如等待200ms再应答,那么这个时候返回的窗口大小就是 1M;一定要记得,窗口越大,网络吞吐量就越大,传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;那么所有的包都可以延迟应答么?肯定也不是; 数量限制:每隔N个包就应答一次;时间限制:超过最大延迟时间就应答一次;具体的数量和超时时间,依操作系统不同也有差异;一般N取2,超时时间取200ms; 在延迟应答的基础上,我们发现,很多情况下,客户端服务器在应用层也是 "一发一收" 的。意味着客户端给服务器说了 "How are you",服务器也会给客户端回一个 "Fine, thank you"; 那么这个时候ACK就可以搭顺风车,和服务器回应的 "Fine,thank you" 一起回给客户端 创建一个TCP的socket,同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区; 调用write时,数据会先写入发送缓冲区中;如果发送的字节数太长,会被拆分成多个TCP的数据包发出;如果发送的字节数太短,就会先在缓冲区里等待,等到缓冲区长度差不多了,或者其他合适 的时机发送出去;接收数据的时候,数据也是从网卡驱动程序到达内核的接收缓冲区;然后应用程序可以调用read从接收缓冲区拿数据;另一方面,TCP的一个连接,既有发送缓冲区,也有接收缓冲区,那么对于这一个连接,既可以读数据,也可以写数据。这个概念叫做 全双工由于缓冲区的存在,TCP程序的读和写不需要一一匹配,例如: 写100个字节数据时,可以调用一次write写100个字节,也可以调用100次write,每次写一 个字节;读100个字节数据时,也完全不需要考虑写的时候是怎么写的,既可以一次read 100个字 节,也可以一次read一个字节,重复100次; 粘包问题 首先要明确,粘包问题中的 "包" ,是指的应用层的数据包。在TCP的协议头中,没有如同UDP一样的 "报文长度" 这样的字段,但是有一个序号这样的字 段。站在传输层的角度,TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。站在应用层的角度,看到的只是一串连续的字节数据。那么应用程序看到了这么一连串的字节数据,就不知道从哪个部分开始到哪个部分,是一个 完整的应用层数据包。那么如何避免粘包问题呢?归根结底就是一句话,明确两个包之间的边界。 对于定长的包,保证每次都按固定大小读取即可;例如上面的Request结构,是固定大小 的,那么就从缓冲区从头开始按sizeof(Request)依次读取即可;对于变长的包,可以在包头的位置,约定一个包总长度的字段,从而就知道了包的结束位 置;对于变长的包,还可以在包和包之间使用明确的分隔符(应用层协议,是程序猿自己来定 的,只要保证分隔符不和正文冲突即可);思考:对于UDP协议来说,是否也存在 "粘包问题" 呢? 对于UDP,如果还没有上层交付数据,UDP的报文长度仍然在。同时,UDP是一个一个把数 据交付给应用层。就有很明确的数据边界。站在应用层的站在应用层的角度,使用UDP的时候,要么收到完整的UDP报文,要么不收。 不会出现"半个"的情况。 TCP异常情况进程终止:进程终止会释放文件描述符,仍然可以发送FIN。和正常关闭没有什么区别。 机器重启:和进程终止的情况相同。 机器掉电/网线断开:接收端认为连接还在,一旦接收端有写入操作,接收端发现连接已经不在了,就会进行reset。即使没有写入操作,TCP自己也内置了一个保活定时器,会定期询问对方是否还在。如果对方不在,也会把连接释放。 另外,应用层的某些协议,也有一些这样的检测机制。例如HTTP长连接中,也会定期检测对方的状态。 例如QQ,在QQ断线之后,也会定期尝试重新连接。 TCP小结为什么TCP这么复杂?因为要保证可靠性,同时又尽可能的提高性能。 可靠性: 校验和序列号(按序到达)确认应答超时重发连接管理流量控制拥塞控制提高性能: 滑动窗口快速重传延迟应答捎带应答其他: 定时器(超时重传定时器,保活定时器,TIME_WAIT定时器等) 基于TCP应用层协议 HTTPHTTPSSSHTelnetFTPSMTP当然,也包括你自己写TCP程序时自定义的应用层协议; UDP协议 UDP协议端格式UDP传输的过程类似于寄信。 无连接知道对端的IP和端口号就直接进行传输,不需要建立连接; 不可靠没有任何安全机制,发送端发送数据报以后,如果因为网络故障该段无法发到对方,UDP协议层也不会给应用层返回任何错误信息; 面向数据报应用层交给UDP多长的报文,UDP原样发送,既不会拆分,也不会合并; 用UDP传输100个字节的数据: 如果发送端一次发送100个字节,那么接收端也必须一次接收100个字节;而不能循环接收10次, 每次接收10个字节。 缓冲区UDP只有接收缓冲区,没有发送缓冲区: UDP没有真正意义上的 发送缓冲区。发送的数据会直接交给内核,由内核将数据传给网络层协议 进行后续的传输动作;UDP具有接收缓冲区,但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一 致;如果缓冲区满了,再到达的UDP数据就会被丢弃;UDP的socket既能读,也能写,这个概念叫做 全双工 大小受限UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。 基于UDP的应用层协议 NFS:网络文件系统TFTP:简单文件传输协议DHCP:动态主机配置协议BOOTP:启动协议(用于无盘设备启动)DNS:域名解析协议当然,也包括你自己写UDP程序时自定义的应用层协议。 TCP/UDP对比我们说了TCP是可靠连接,那么是不是TCP一定就优于UDP呢?TCP和UDP之间的优点和缺点,不能简单,绝对的进行比较 TCP用于可靠传输的情况,应用于文件传输,重要状态更新等场景;UDP用于对高速传输和实时性要求较高的通信领域,例如,早期的QQ,视频传输等。另外 UDP可以用于广播;归根结底,TCP和UDP都是程序员的工具,什么时机用,具体怎么用,还是要根据具体的需求场景去判定。 网络层重点协议在复杂的网络环境中确定一个合适的路径。 IP协议协议头格式如下: |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |