1.TCP:传输控制协议---< >

1.TCP:传输控制协议

1.1引言

IP和UDP协议,没有实现差错纠正;对于以太网和基于其上的其余协议,协议都提供了必定次数的重试,若是仍是不成功则放弃. 通讯媒介可能会丢失或则改变传递的消息,出现了通讯的问题.这个课题的最重要的理论研究者是劳德.香农,在1948年给出[S48]缓存

通讯差错问题的解决:服务器

  • 使用差错校验码(添加一些冗余的比特,即便比特丢失丢失,真实的信息也能够被恢复出来)
  • 自动重复请求(Automatic Repeat Request,ARQ),包含了TCP协议

1.1.1 ARQ和重传

处理分组丢失(比特差错)的方法是重发分组直到他被正确的接受.判断方法?markdown

  1. 接收方是否已经收到分组
  2. 接收方接收到的分组是否与执以前发送方的同样

ACK(acknowledge)网络

  • 发送方发送一个分组,而后等待一个ACK.当接收方接收到这个分组时,它发送对应的ACK,整个过程就这样继续.

ACK出现的问题:socket

  1. 对一个请求ACK应该等待多久?
  2. 若是ACK丢失了怎么办?
  3. 若是分组被接受到了,可是里面有错怎么办?

ACK出现的问解决:spa

  • 问题1:后面讨论
  • 问题2:再次发送原分组
  • 问题3:通常使用校验和与CRC,当接收方接受到一个含有差错的分组,它不发送ACK.最后,发送方重发完整分组到无差错的分组.

接收方接收到重复分组的解决办法指针

使用序列号,发送方为每一个分组分配序列号,由分组自身携带着.接收方使用这个序列号码来判断是否已经见过这个分组,若是见过则丢弃.code

1.1.2 分组窗口和滑动窗口

  • 存在于发送方和接收方,窗口结构便于记录在发送方和接收方数据的流动
  • 发送方窗口:记录哪些分组能够释放,哪些分组能够被释放,哪些分组正在正在等待ACK,以及哪些分组不能被发送.
  • 接收方窗口:记录着哪些分组已经被接受和确认,哪些分组是下一步指望的(和已经分配多少内存来他们),以及哪分组即便被接受也将会由于内存限制而被丢弃.
  • window size(窗口大小):分组窗口中的分组数量(window)
  • window(分组窗口):发送方注入但尚未完成确认的分组集合

1.1.3 变量窗口:流量控制和拥塞控制

流量控制(flow control):处理当接收方相对发送方太慢产生的问题,在接收方跟不上的时候会强迫发送方慢下来.orm

flow control的操做方法接口

  1. rate_based(速率)流量控制:给发送方指定某个速率,同时确保数据永远不能超过这个速率.这种类型的流量控制最适合流应用程序,可被用于广播和组播发现.
  2. window-based(基于窗口)流量控制,是使用滑动窗口时最流行的方法.窗口大小不是固定的,是随时间而变更的.必须使用window advertisement或则简单地称为window update(窗口更新)---让接收方能够通知发送方使用多大的窗口

流量控制原理

修改发送方的窗口大小:分组没有收到任何一个ACK以前,发送方注入W个分组到网络,若是发送方和接收方足够快,网络没有丢失一个分组以及有无穷的空间的话,这就意味着通讯正比于(SW/R)b/s,这里W是窗口大小,S是分组大小(比特单位计算),R是往返时间.当来自接收方的窗口夹带着发送方的值W时,那么发送方的所有速率就被限制而不能超越接收方.这种方法能够很好的保护接收方.可是对于中间的网络呢?在接收方和发送方可能会有有限内存的路由器,他们与低速网络链路抗争着,这种状况出现了,发送方的速率可能超过某个路由器的能力,从而致使丢包.这种状况由 congestion control(拥塞控制)的流量控制形式来处理.

congestion control(拥塞控制)

拥塞控制涉及发送方以及减速以不低于压垮其与接收方之间的网络.使用一个窗口通告来告诉发送方为接收方减速.

1.1.4 设置重传超时

重传超时应该是多大?

round-trip-time estimation(往返时间估计),这是一个统计过程.总的来讲,选择一组RTT样本的平均值做为真实的RTT是最有可能的.这个RTT值是动态的.

1.2 TCP的引入

1.2.1 TCP服务模型

TCP提供了一种connection-oriented(面向链接),可靠的字节流服务.

  • 面向链接:TCP的两个应用程序之间必须在他们可交换数据以前,经过联系来创建一个TCP链接.例如,打电话,等待另一方接听电话并说"喂",而后再说"找谁?".这正是TCP链接的两个端点在相互通讯.
  • 字节流服务:抽象概念给应用程序使用,一端给TCP字节流,一样的字节流会出现另一端.每一个端点独立选择本身的读和写大小.TCP不会解读字节流里的字节内容,他不知道正在交换的数据字节是否是二进制数据,ASCII字符,EBCDIC字符或做其余东西.对于这个字节流的解读取决于链接中的每一个端点的应用程序.

1.2.2 TCP中的可靠性

可靠性:

  • 提供了一个字节流接口,TCP必须把一个发送应用程序的字节流转换成一组IP能够携带的分组,称为组包(packetization).分组包含序列号,在TCP中表明了每一个分组第一个字节在整个数据流中的字节偏移,而非分组号.这容许分组在传送中是可变的大小的,而且容许他们组合,称为从新组包(repacketization).应用程序数据被打散成TCP认为最佳大小的快来发送,每一个报文段大小与分片的单个IP数据报大小不一样.TCP传给IP的块称为报文段(segment)
  • TCP维持了强制的校验和:校验和涉及他的头部,任何相关程序数据和IP头部的全部字段.这是一个端到端的伪头部,用于检测传送中引入的比特差错.
  • 重传计时器:当TCP发送一组报文段时,他一般设置一个重传计时器,等待对方的确认接收.当ACK到达时再更新超时.若是一个ACK没有及时接收到,这个报文段就会被重传.
  • ACK:当TCP接收到链接的另外一端的数据时,他会发送一个确认.
  • TCP给应用程序提供了双工服务:数据能够同时往两个方向流动,两个方向相互独立.所以,链接的每一个端点必须对每一个方向的维持数据流的一个序列号.
  • 使用序列号:一个TCP接收端可丢弃重复的报文段和记录以及杂乱无序的报文段

1.3 TCP头部和封装

每一个TCP头部包含了源和目的的端口号码.这两个值与IP头部中的源和目的地IP地址一块儿,惟一性地标识了每一个链接.在TCP术语中,一个IP地址和一个端口的组合被称为一个端点(endpoint)或则套接字(socket).每一个TCP链接都有一对套接字或端点(四元组,由客户机IP地址,客户机端口号,服务器IP地址以及服务器端口组成惟一标识)

  • 序列号(Sequence Number)字段标识了TCP发送端到TCP接收端的数据流的一个字节,该字节表明着包含该序列号的报文段的第一个字节.范围0-2^32-1,每一个被交换的字节都已经被编号,确认号字段(ACK号/ACK字段)包含的值是该确认号的发送方期待的接受的下一个序列号.即最后被成功接收的数据字节的序列号加1.在ack字段被启用有效.

SYN字段:创建新链接时,从客户机发送服务器的第一个报文段的SYN位字段被启用.这样的报文段称为SYN报文段.序列号包含了本次链接的这个方向上要使用的第一个序列号.常常是一个随机数(Initial Sequence Number,ISN)

  • CWR(Congestion Window Reduce)---拥塞窗口减少标识(发送下降它的发送速率),收到了设置ECE标识的包,减少发送窗口大小来下降发送的速率
  • ECE(ECN Echo)---ECN回显(发送方接收到了一个更早的拥塞通知),三次握手的时候代表TCP端是具有ECN功能的,在数据传输的时候标识收到的TCP包的IP头部ECN被设置成11,即网络拥堵
  • URG(Urgent)---紧急(紧急指针字段有效--不多使用),标识报文段发送的数据是否包含紧急数据,URG=1标识有紧急数据,这时的紧急指针字段才有效果
  • ACK---确认(确认字段有效--链接创建之后通常是启用状态),ACK=1时,确认的字段才有效,TCP规定,创建链接后ACK必须是1
  • PSH(PUSH)---推送(接收方应尽快给应用程序传送这个数据---没被可靠地实现或用到),PSH=1表示,应该立马把数据推送给应用程序,而不是缓存起来
  • RST---重置链接(链接取消,常常是错误),RST=1表示TCP出现了严重错误(主机崩了),必须释放链接,从新创建链接
  • SYN---用于初始化一个链接的同步序列号,SYN=1,ACK=0表示这是一个创建链接的报文段,当SYN=1,ACK=1表示双方赞成创建链接.SYN=1,只能表示这是一个创建链接或则赞成创建链接的报文.只有在前两次握手中SYN才是1
  • FIN---标记数据是否发送完成.若是FIN=1,表示数据发送完成,能够释放链接
  • TCP校验和字段覆盖了TCP的头部和数据以及头部中的一些字段.
  • 紧急指针(Urgent Pointer)字段只有在URG为字段被设置时才有效.这个指针是一个必需要加到报文段的序列号字段上的正偏移,以产生紧急数据的最后一个字节的序列号.TCP的紧急机制是发送方给另一端提供特殊标识数据的方法,

2.TCP 链接管理

3.TCP 超时与重传

4.TCP 数据流与窗口管理

5.TCP 拥塞控制

6.TCP 保活机制