码迷,mamicode.com
首页 > 其他好文 > 详细

TCP传输控制协议

时间:2017-04-29 11:02:02      阅读:170      评论:0      收藏:0      [点我收藏+]

标签:.com   重要   定时   技术分享   特征   question   处理   延迟   soc   

 

TCP

在TCP/IP协议模型中, 传输层协议有TCP和UDP, 这里主要介绍下可靠传输TCP协议, 目前是传输层协议首选.

 

特点

  • 面向数据流(字节流形式)
  • 虚电路连接
  • 有缓冲传输(提供push机制 )
  • 无结构数据流(无边界)
  • 全双工

 

连接建立

socket接口使用 connect()时建立连接,  采用三次握手,  请看下图 :

 

技术分享

 

在这个过程中完成了几个重要功能 :

  1. 建立连接, 做好传送数据准备.
  2. 协商各自报文段初始序号ISN( 任意选取, TCP准规定不可为1, 其中一个原因是避免IP欺骗).
  3. 协商报文段最大长度MSS.

 

为什么要三次握手 ?

考虑正常情况:  主机A给主机B发送数据包, 在网络中丢失了. 主机A定时器到期后未收到来自主机B的确认, 于是A重新发送数据包, 主机B收到再发送确认.  如果之前的数据包没有丢失呢 ? 只是延迟了比较长的时间.  那么这个失效的数据包又重新发给主机B, 主机B以为A要建立连接, 会给A发送确认,  同意建立连接.   A肯定不会理它了,  所以主机B一直在那白白地等A传送数据, 所以采用三次握手能很好解决这个问题. 其他精彩回答可参考  https://www.zhihu.com/question/24853633

 

可靠传输

1.防止丢失

如果限定一个时间之内未收到报文段的确认, 则认为该报文丢失, 进行重传.  超时定时器设定采用自适应动态算法.

技术分享

 

2.防止重复和乱序

采用唯一序号机制. 这种方法相当于给每个字节编号, 体现了TCP面向数据流的特征

3.确认机制

1.确认指明期望收到下个报文段的序号, 而不是已经收到的报文段序号.

2.累计确认(确认信息报告已经累积了多少个字节的数据).

3.捎带确认(不单独发送确认信息, 捎带在自己发送的报文段中).

 

连接关闭

断开连接使用四次挥手,  在客户端调用socket接口 close() 后发送FIN数据包,  参考下图:

技术分享

 

TCP连接是全双工的, 两个方向上都要关闭, 原则是发起关闭的一方发送FIN字段,  另一方接收到后必须发送关闭的确认. 从图中可以看出, 当收到FIN并不是立即关闭, 它是先发送确认, 然后再继续发送自己的FIN请求.

需要注意的是 当客户端收到关闭确认ACK之后, 它仍然可以接受服务器的数据, 并且向服务器发送确认信息, 一个仅包含确认信息的报文不占用序号.

 

客户端最后发送ACK后进入TIME_WAIT状态而不是CLOSED, 因为最后的这个ACK可能丢失,  如果是CLOSED话就已经断开连接了.  服务器方的这个连接关闭就会出错. 所以这里应该等待一段时间再进入CLOSED状态, 这个时间就是最大报文生存周期(MSL).

 

异常关闭:   发送RST报文段,  立即停止传输,  关闭连接, 释放资源.

半开放连接: 引入保活定时器, 指点时间之内仍然没有数据通信, 则发送侦查报文, 根据不同情况进行处理.

 

TCP传输控制协议

标签:.com   重要   定时   技术分享   特征   question   处理   延迟   soc   

原文地址:http://www.cnblogs.com/tanxing/p/6784489.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!