备战秋招——计算机网络(二)

TCP
TCP 特点

TCP 是面向连接的运输层协议,一个应用进程在向另一个进程发送数据之前,两个进程必须先建立 TCP连接,发送某些预备报文段,建立确保数据传输的参数。作为 TCP 连接建立的一部分,连接双方都将初始化与 TCP 连接相关的许多状态变量。这种连接不是电路交换网络中的端到端电路这种物理连接,而是一种逻辑连接,TCP 报文要先传送到 IP 层加上 IP 首部后,再传到数据链路层,加上链路层的首部和尾部后才离开主机发送到物理层。
TCP 连接提供全双工服务,允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都有各自的发送缓存和接收缓存,用来临时存放通信数据。在发送时,应用程序把数据传送给 TCP 缓存后就可以做自己的事,而 TCP 在合适的时候会把数据发送出去。在接收时,TCP 把收到的数据放入缓存,上层应用程序会在合适的时候读取缓存数据。
TCP 连接是点对点的,每一条 TCP 连接只能有两个端点,即只能是单个发送方和单个接收方之间的连接。
TCP 提供可靠的交付服务,通过 TCP 连接传送的数据无差错、不丢失、不重复,按序到达。
TCP 是面向字节流的,流是指流入到进程或从进程中流出的字节序列。面向字节流的含义是:虽然应用程序和 TCP 的交互是一次一个数据块,但是 TCP 把应用程序交下来的数据仅仅看成一连串无结构的字节流。TCP 不保证接收方应用程序收到的数据块和发送方应用程序发出的数据块具有对应大小的关系,但是接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。接收方应用程序必须
有能力识别收到的字节流,并把它还原成有意义的应用层数据。
可靠传输协议 ARQ
自动重传请求 ARQ 包括了停止等待协议、回退 N 步协议和选择重传协议,后两种结合了窗口机制,属于连续 ARQ 协议
TCP 可靠原理
TCP 的可靠传输包含很多机制,例如使用检验和来检测一个传输分组中的比特错误、使用定时器来用于超时重传一个分组、使用序号来检测丢失的分组和冗余副本、使用确认来告诉发送方确认的分组信息、使用否定确认来告诉发送方某个分组未被正确接收。TCP 的发送方仅需维持已发送过但未被确认的字节的最小序号和下一个要发送的字节的序号,从这种角度看 TCP 更像一个 GBN 协议。但是 TCP 和 GBN 有一些显著的区别,许多 TCP 实现会将正确接收但失序的报文段缓存起来。当分组 n 丢失时,GBN 会重传 n 之后的所有分组,但是 TCP 至多只会重传分组n。对 TCP 提出的一种修改意见是选择确认,它允许 TCP 接收方有选择地确认失序报文段,而不是累积地确认最后一个正确接收的有序报文段,从这个角度看 TCP 又像 SR 协议。因此 TCP 的差错恢复机制是一种 GBN 和 SR 的结合体。除此之外,TCP 还使用流量控制和拥塞控制来保证可靠性。
滑动窗口
滑动窗口以字节为单位。发送端有一个发送窗口,窗口中的序号是允许发送的序号,窗口的后沿是已经发送并且确认的序号,窗口的前沿是不允许发送的序号。窗口的后沿可能不动(代表没有收到新的确认),也有可能前移(代表收到了新的确认),但是不会后移(不可能撤销已经确认的数据)。窗口的前沿一般是向前的,也有可能不动(表示没有收到新的请求或对方的接收窗口变小),也有可能收缩,但 TCP 强烈不建议这么做,因为发送端在收到通知前可能已经发送了很多数据,此时如果收缩窗口可能会产生错误。
滑动窗口的状态需要3个指针p1,p2 和 p3。p1 之前的序号表示已经发送并且确认的序号,p1~p2 的序号表示已经发送但还没有确认的序号,p2~p3 表示允许发送的序号,也叫可用窗口,p1~p3 表示发送窗口,p3 之后的序号表示不可发送的序号。
发送缓存用来暂时存放发送应用程序传给发送方 TCP 准备发送的数据和已经发送但还没确认的数据。接收缓存用来暂时存放按序到达的但尚未被应用程序读取的数据以及未按序到达的数据。
注意三点:① 发送窗口根据接收窗口设置,但并不总是一样大,还要根据网络的拥塞情况调整。② 对于不按序到达的数据,TCP 通常存放在接收窗口,等到字节流缺少的字节收到后再按序交付上层应用程序。③ 接收方必须有累积确认功能,可以减小传输开销,可以在合适的时候发送确认,也可以在自己有数据需要发送时捎带确认。但是接收方不能过分推迟发送确认,不能超过0.5秒。
流量控制
如果某个应用程序读取数据的速度较慢,而发送方发送得太多、太快,发送的数据就会很容易使连接的接收缓存溢出,TCP 为它的应用程序提供了流量控制以消除发送方使接收方缓存溢出的可能性。流量控制是一个速度匹配服务,即发送方的发送速率与接收方的应用程序读取速率相匹配。
TCP 通过让发送方维护一个接收窗口的变量来提供流量控制。通俗地说,接收窗口用于给发送方一个指示,该接收方还有多少可用的缓存空间,因此方法方的发送窗口不能超过接收方给出的接收窗口的数值。因为 TCP 是全双工通信,在连接两端的发送方都各自维护一个接收窗口。
当接收窗口 rwnd 减小到 0 时,就不再允许发送方发送数据了。但是可能存在一种情况,当发生了零窗口报文段不久后,发送方的接收缓存又有了一些存储空间,因此又发生了新的报文说明自己的接收窗口大小,但是这个报文可能会在传输过程中丢失。接收方就会一直等待发送方的非零窗口通知,而发送方也一直在等待接收方发送数组,形成一种死锁的状态。为了解决这个问题,TCP 为每一个连接设有一个持续计时器,只要 TCP 连接的一方收到对方的零窗口通知就启动该计时器,到期后发送一个零窗口探测报文,如果仍为 0 就重新设置计时器的时间,如果对方给出了新的窗口值就可以解决可能出现的死锁问题。
还有一种问题叫做糊涂窗口综合症,当接收方处理接收缓冲区数据很慢时,就会使应用进程间传送的有效数据很小, 极端情况下有效数据可能只有 1 字节但传输开销却有 40 字节(20字节的 IP 头以及 20 字节的 TCP 头) ,导致网络效率极低。为了解决这个问题,可以让接收方等待一段时间,使得接收缓存有
足够的空间容纳一个最长报文段或者等到接收缓存已有一半的空闲空间。发送方也不要发送太小的报文,而是把数据积累成足够大的报文或达到接收方缓存空间的一半时才发送。
拥塞控制
网络中对资源需求超过了资源可用量的情况就叫做拥塞。当吞吐量明显小于理想的吞吐量时就出现了轻度拥塞,当吞吐量随着负载的增加反而下降时,网络就进入了拥塞状态。当吞吐量降为 0 时,网络已无法正常工作并陷入死锁状态。拥塞控制就是尽量减少注入网络的数据,减轻网络中的路由器和链路的负担。拥塞控制是一个全局性的问题,它涉及网络中的所有路由器和主机,而流量控制只是一个端到端的问题,是两个端点之间通信量的控制。
根据网络层是否为运输层拥塞控制提供显式帮助可以将拥塞控制的方法区分为两种:端到端拥塞控制和网络辅助的拥塞控制。TCP 使用端到端的拥塞控制,因为 IP 层不会向端系统提供显式的网络拥塞反馈。TCP 所采取的方法是让每一个发送方根据所感知到的网络拥塞程度来限制其向连接发送数据的速率。如果一个 TCP 发送方感知到它到目的地之间的路径上没什么拥塞则会增加发送速率,如果发送方感知到拥塞就会降低其发送速率。限制发送速率是通过拥塞窗口来实现的,它对发送方能向网络中发送流量的速率进行了限制。判断拥塞是通过超时或者连续接收到 3 个冗余 ACK 实现的。
TCP 的拥塞控制算法主要包括了慢启动、拥塞避免和快恢复。慢启动和拥塞避免是 TCP 的强制部分,差异在于对收到的 ACK 做出反应时 cwnd 增加的方式,慢启动比拥塞避免要更快地增加 cwnd 的长度。快恢复是推荐部分,对 TCP 发送方不是必需的。
TCP 连接和释放机制
三次握手
TCP 是全双工通信,任何一方都可以发起建立连接的请求,假设 A 是客户端,B 是服务器。初始 A 和 B 均处于 CLOSED 状态,B 会创建传输进程控制块 TCB 并进入 LISTEND 状态,监听端口是否收到了 TCP 请求以便及时响应。
当 A 要发生数据时就向 B 发送一个连接请求报文,TCP 规定连接请求报文的 SYN=1,ACK=0,SYN 不可以携带数据,但要消耗一个序号,假设此时 A 发送的序号 seq 为 x。发送完之后 A 就进入了 SYNSENT 同步已发送状态。
当 B 收到 A 的连接请求报文后,如果同意建立连接就会发送给 A 一个确认连接请求报文,其中SYN=1,ACK=1,ack=x+1,seq=y,ack 的值为 A 发送的序号加 1,ACK 可以携带数据,如果不携带的话则不消耗序号。发送完之后,B进入 SYN-RCVD 同步已接收状态。
当 A 收到 B 的确认连接请求报文后,还要对该确认再进行一次确认,报文的 ACK=1,ack=y+1,seq=x+1,发送后 A 进入 ESTABLISHED 状态,当 B 接收到该报文后也进入 ESTABLISHED 状态,客户端会稍早于服务器端建立连接。
三次握手的原因主要有两个目的,信息对等和防止超时。
从信息对等的角度看,双方只有确定 4 类信息才能建立连接,即 A 和 B 分别确认自己和对方的发送和接收能力正常。在第二次握手后,从 B 的角度看还不能确定自己的发送能力和对方的接收能力,只有在第三次握手后才能确认。
三次握手也是防止失效连接突然到达导致脏连接,网络报文的生存时间往往会超过 TCP 请求超时时间,A 的某个超时连接请求可能会在双方释放连接之后到达 B,B 会误以为是 A 创建了新的连接请求,然后发送确认报文创建连接。因为 A 机器的状态不是 SYN_SENT,所以直接丢弃了 B 的确认数据。如果是两次握手,连接已经建立了,服务器资源被白白浪费。如果是三次握手,B 由于长时间没有收到确认信息,最终超时导致创建连接失败,因此不会出现脏连接。
TCP 和 UDP 的区别
TCP 是面向连接的,而 UDP 是无连接的,发送数据之前不需要建立连接,减少了开销和发送数据之前的时延。
TCP 保证数据的可靠传输,UDP 使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的连接状态。
TCP 是面向字节流的,UDP 是面向报文的,发送方的 UDP 对应用程序交下来的报文,在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文既不拆分也不合并,而是保留这些报文的边界。如果报文太长,IP 层在传送时可能需要分片,如果报文太短,会使 IP 数据报首部的相对长度太大,都会降低 IP层的效率。
TCP 有拥塞控制,UDP 没有拥塞控制,因此网络中出现的拥塞不会降低源主机的发送速率。这对某些实时应用很重要,很多实时应用如 IP 电话、实时视频会议等要求源主机以恒定的速率发送数据,并且允许在网络发生拥塞时丢失一些数据,但却不允许网络有太大的时延,UDP 正好适合这种要求。
TCP 是点到点之间的一对一通信,UDP 支持一对一、一对多和多对多的交互通信。UDP 的首部开销很小,只有 8 字节,相比 TCP 的 20 字节要短。

你可能感兴趣的:(备战秋招,java,网络)