1024程序员节,回顾tcp协议的一些重点。
1024在外界的众多小伙伴看来,可能是某一不可描述的知名网站,但是(敲黑板,划重点)这是我们程序猿的节日啊!
这一年节日传播,真可谓是陆海空全面轰炸。
为了让程序员们过好这个节日,他们身边的人也是操碎了心。在望京、751、南锣鼓巷、奥林匹克公园等多处北京街头,惊现“快闪寻人”。人们手举各式各样的标语,倡议程序员在1024程序员节当天,不加班!
2015年10月24日(即1024这天)号召全社会关爱程序员,给他们专属于他们自己的自由的一天!让他们少一点儿被宅,多一分与异性的接触;少一点儿熬夜,多一些充足的睡眠;少一点儿敲键盘,多一些锻炼的时间。
TCP提供一种面向连接的、可靠的字节流服务。其中,面向连接意味着两个使用TCP的应用(通常是一个客户和一个服务器)在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中,仅有两方进行彼此通信;而字节流服务意味着两个应用程序通过TCP链接交换8bit字节构成的字节流,TCP不在字节流中插入记录标识符。
对于可靠性,TCP通过以下方式进行保证:
目的是检测数据在传输过程中的任何变化,若校验出包有错,则丢弃报文段并且不给出响应,这时TCP发送数据端超时后会重发数据;
既然TCP报文段作为IP数据报来传输,而IP数据报的到达可能会失序,因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序,然后才交给应用层;
丢弃重复数据:对于重复数据,能够丢弃重复数据;
应答机制:当TCP收到发自TCP连接另一端的数据,它将发送一个确认。这个确认不是立即发送,通常将推迟几分之一秒;
当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段;
TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据,这可以防止较快主机致使较慢主机的缓冲区溢出,这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。
TCP的可靠传输是通过确认和超时重传的机制来实现的,而确认和超时重传的具体的实现是通过以字节为单位的滑动窗口机制来完成。
端到端传输中控制流量大小并保证传输可靠性(未收到ack就不滑动)。
TCP的滑动窗口主要有两个作用,一是提供TCP的可靠性,二是提供TCP的流控特性。同时滑动窗口机制还体现了TCP面向字节流的设计思路。
当发送窗口和接收窗口的大小都等于 1时,就是停止等待协议。
当发送窗口大于1,接收窗口等于1时,就是回退N步协议。
当发送窗口和接收窗口的大小均大于1时,就是选择重发协议
后退n协议
停等协议虽然实现简单,也能较好的适用恶劣的网络环境,但是显然效率太低。所以有了后退n协议,这也是滑动窗口协议真正的用处,这里发送的窗口大小为n,接受方的窗口仍然为1。具体看下面的图,这里假设n=9:
首先发送方一口气发送10个数据帧,前面两个帧正确返回了,数据帧2出现了错误,这时发送方被迫重新发送2-8这7个帧,接受方也必须丢弃之前接受的3-8这几个帧。
选择重传协议
后退n协议的另外一个问题是,当有错误帧出现后,总是要重发该帧之后的所有帧,毫无疑问在网络不是很好的情况下会进一步恶化网络状况,重传协议便是用来解决这个问题。原理也很简单,接收端总会缓存所有收到的帧,当某个帧出现错误时,只会要求重传这一个帧,只有当某个序号后的所有帧都正确收到后,才会一起提交给高层应用。重传协议的缺点在于接受端需要更多的缓存。
窗口的动作
称窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时。
当窗口右边沿向右移动时将允许发送更多的数据,我们称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了T C P的接收缓存时。
当右边缘向左移动时,称之为窗口收缩。
TCP的拥塞控制由4个核心算法组成:“慢启动”(Slow Start)、“拥塞避免”(Congestion voidance)、“快速重传 ”(Fast Retransmit)、“快速恢复”(Fast Recovery)
发送方维持一个拥塞窗口cwnd,每经过一个传输轮次,拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过“传输轮次”更加强调:把拥塞窗口cwnd所允许发送的报文段都连续发送出去,并收到了对已发送的最后一个字节的确认。
另,慢开始的“慢”并不是指cwnd的增长速率慢,而是指在TCP开始发送报文段时先设置cwnd=1,使得发送方在开始时只发送一个报文段(目的是试探一下网络的拥塞情况),然后再逐渐增大cwnd。
当 cwnd拥塞窗口 < ssthresh 慢开始门限时,使用上述的慢开始算法。
当 cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。改为加法。
快速重传:
那就是收到3个相同的ACK。TCP在收到乱序到达包时就会立即发送ACK,TCP利用3个相同的ACK来判定数据包的丢失,此时进行快速重传,快速重传做的事情有:
1.把ssthresh设置为cwnd的一半
2. cwnd再设置为ssthresh的值(具体实现有些为ssthresh+3)
3.重新进入拥塞避免阶段,加法增大。
他们之间的第一点并且最重要的区别是:TCP是面向连接的协议,而UDP是无连接的协议。这意味着当一个客户端和一个服务器通过TCP发送数据之前,必须先建立连接,他们可以通过TCP发送数据。建立连接的过程也被称为TCP握手,他通过控制消息在客户端和服务器之间互换来实现。下面的图形象描述了TCP握手过程。客户端,它也是TCP连接的发起者,发送一个SYN消息给服务器,该服务器端正在监听某个TCP端口。服务器接收该消息并发送一个SYN-ACK消息,客户端接受到该消息之后会再回一个ACK消息。一旦服务器收到ACK消息,TCP连接就建立成功,准备数据传输了。另一方面,UDP是无连接的协议,和点对点连接之前不需要发送消息。这就是为什么,UDP更加适合消息的多播发布,从单个点向多个点传输消息。
TCP提供交付保证,这意味着一个使用TCP协议发送的消息是保证交付给客户端的。如果消息在传输过程中丢失,那么它将重发,这是由TCP协议本身控制的。另一方面,UDP是不可靠的,它不提供任何交付的保证。一个数据报包在运输途中可能会丢失。这就是为什么UDP是不适合保证交付的项目。
除了提供交付保证,为TCP也保证了消息的有序性。该消息将以从服务器端发出的同样的顺序发送到客户端,尽管这些消息到网络的另一端时可能是无序的。TCP协议将会为你排好序。UDP不提供任何有序性或序列性的保证。数据包将以任何可能的顺序到达。这就是为什么TCP是适合需要顺序交付方式的应用,尽管有基于UDP的协议通过使用序列号和重传来提供有序和可靠性的应用,如TIBCO Rendezvous,他实际上就是一个基于UDP的应用。
TCP不保存数据的边界,而UDP保证。在传输控制协议,数据以字节流的形式发送,并没有明显的标志表明传输信号消息(段)的边界。在UDP中,数据包单独发送的,只有当他们到达时,才会再次集成。包有明确的界限来哪些包已经收到,这意味着在消息发送后,在接收器接口将会有一个读操作,来生成一个完整的消息。虽然TCP也将在收集所有字节之后生成一个完整的消息,但是这些信息在传给传输给接受端之前将储存在TCP缓冲区,以确保更好的使用网络带宽
总而言之,TCP速度比较慢,而UDP速度比较快,因为TCP必须创建连接,以保证消息的可靠交付和有序性,他需要做比UDP多的多的事。这就是为什么UDP更适用于对速度比较敏感的应用,例如:在线视频媒体,电视广播和多人在线游戏。
由于上述的开销,TCP被认为是重量级的协议,而与之相比,UDP协议则是一个轻量级的协议。因为UDP传输的信息中不承担任何间接创造连接,保证交货或秩序的的信息。这也反映在用于承载元数据的头的大小。
TCP具有比UDP更大的头。一个TCP数据包报头的大小是20字节,UDP数据报报头是8个字节。TCP报头中包含序列号,ACK号,数据偏移量,保留,控制位,窗口,紧急指针,可选项,填充项,校验位,源端口和目的端口。而UDP报头只包含长度,源端口号,目的端口,和校验和。
TCP有流量控制。在任何用户数据可以被发送之前,TCP需要三数据包来设置一个套接字连接。TCP处理的可靠性和拥塞控制。另一方面,UDP不能进行流量控制。
在互联网中,TCP和UDP都运行在哪些环境中了?在了解了TCP和UDP之间的关键差异之后,我们可以很容易地得出结论,哪种情况适合他们。由于TCP提供可靠交付和有序性的保证,它是最适合需要高可靠并且对传输时间要求不高的应用。UDP是更适合的应用程序需要快速,高效的传输的应用,如游戏。UDP是无状态的性质,在服务器端需要对大量客户端产生的少量请求进行应答的应用中是非常有用的。在实践中,TCP被用于金融领域,如FIX协议是一种基于TCP的协议,而UDP是大量使用在游戏和娱乐场所。
基于TCP协议的最好例子是HTTP协议和HTTPS协议,他们几乎存在于互联网的任何地方,实际上,绝大多数你所熟悉的通常协议,都是基于TCP的,例如:Telnet,FTP以及SMTP协议。UDP协议没有TCP协议那么受欢迎,但是也被广泛应用,比如DHCP以及DNS协议,其他还有一些基于UDP的协议如SNMP,TFTP,BOOTP以及NFS(早期版本)。
特别需要记住的是,TCP是面向连接的,可靠的,缓慢的,可靠交付以及保证消息顺序的,而UDP是无连接的,不可靠的,没有序列保证,但是一个快速传输的协议。TCP头开销也比UDP高得多,因为它每个数据包中药发送更多的元数据。值得一提的是,TCP头的大小是20个字节,而UDP头大小是8个字节。如果你不想丢失任何消息,使用TCP协议,而UDP能够高速传输数据,并且丢失少量的数据包是可以接受的,如视频流或在线多玩家游戏。对于基于TCP / UDP协议,运行在Linux上的应用,需要牢记的基本网络命令,如Telnet和netstat,他们极大的帮助调试和排除任何连接问题。
Nagle算法没有禁止小包发送,只是禁止了大量小包的发送,提高网络利用率。
Nagle算法的规则:
(1)如果包长度达到MSS,则允许发送;
(2)如果该包含有FIN,则允许发送;
(3)设置了TCP_NODELAY选项,则允许发送;
(4)未设置TCP_CORK选项时,若所有发出去的小数据包(包长度小于MSS)均被确认,则允许发送;
(5)上述条件都未满足,但发生了超时(一般为200ms),则立即发送。
Nagle算法只允许一个未被ACK的包存在于网络,
这个名字很有意思,简称 SWS.
一看到窗口,我们就应该反应过来这是流量控制中的东西。SWS 是这样一种情况:接收方通告了一个 1 字节的窗口给发送方,然后发送方发送了 1 字节的数据给接收方。当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢,或二者兼而有之;就会使应用进程间传送的报文段很小,特别是有效载荷很小。
极端情况下,有效载荷可能只有1个字节;而传输开销有40字节(20字节的IP头+20字节的TCP头) 这种现象就叫糊涂窗口综合症。。
解决 SWS,有两种办法可以解决此问题:(nagle)(delay-ack)
针对接收方来说,先等一段时间,等到接收缓存有足够的空间了才发出确认。(delay-ack)
针对发送方来说,发送方不要发送太小的报文,而是把数据积累成一个足够大的报文段(达到 MSS),或者是积累到接收方通告窗口大小一半的报文段。(nagle)