zoukankan      html  css  js  c++  java
  • 【计算机网络】-传输层-Internet传输协议-TCP

    【计算机网络】-传输层-Internet传输协议-TCP

    TCP介绍

    在不可靠的互联网上提供一个可靠的端到端字节流
    面向连接的、可靠的、端到端的、基于字节流的传输协议

    TCP位置

    TCP服务模型

    应用程序访问TCP服务

    通过在收发双方创建套接字来实现的

    套接字的地址

    用(IP地址,端口号)来表示的

    知名端口

    1024以下的端口号,如FTP:21,TELNET:23,SMTP:23

    每条连接用(套接字1,套接字2)来表示,是点到点的全双工通道

    TCP不支持

    多播(multicast)和广播(broadcast)

    TCP连接是基于字节流的,而非消息流


    (a) 按单独IP数据报发送的四个512字节的数据块
    (b) 在一次READ调用中传递给应用程序的2048字节的数据

    紧急数据

    对于应用程序发来的数据,TCP可以立即发送,也可以缓存一段时间以便一次发送更多的数据
    为了强迫数据发送,可以使用PUSH标记
    对于紧急数据(urgent data),可以使用URGENT标记

    序列号

    TCP连接上的每个字节都有它自己独有的32位序列号

    TCP协议

    交换数据形式

    发送端和接收段的TCP实体以数据段的形式交换数据
    TCP数据段包含一个20字节的头(选项部分另加)和随后的0个或多个数据字节

    段的大小要求

    每个数据段包括TCP头在内,要适合IP的65515字节净荷大小
    每个网络都有一个最大传输单元(MTU),每个数据段必须适合MTU。实践中,MTU通常为1500字节(以太网的净荷大小)

    滑动窗口

    TCP实体使用滑动窗口协议,确认序号等于接收方希望接收的下一个序号

    超时重传

    超时重传

    TCP数据段的头

    源端口和目的端口

    用于寻找发送端和接收端应用进程
    各占16位

    序列号

    序列号表示该TCP数据段中的第一个TCP数据字节在从TCP发送端向TCP接收端发送的数据字节流中的位置。TCP用序列号对每个字节进行计数
    只有SYN标志置1时序列号字段才有效
    占32位,以字节为单位编号

    确认号

    确认号应当是上次已成功收到数据字节序号加1。只有ACK标志置1时确认号字段才有效
    占32位,以字节为单位编号

    TCP头长度

    给出TCP头部中32位字的数目,即长度单位为32位字,包含可选项域
    占4位
    6位的保留域

    6位的标志位:置1表示有效

    URG:紧急指针有效,和紧急指针配合使用,发送紧急数据
    ACK:确认号是否有效
    PSH:指示接收方应该尽快将这个报文段交给应用层,不做缓存
    RST:重置一个已混乱的连接
    SYN:用来发起一个连接
    FIN:发端完成发送任务后, FIN用于释放连接

    窗口大小

    • 用于基于可变滑动窗口的流控,指示发送方从确认号开始可以再发送窗口大小的字节流,窗口大小为字节数
    • 占16位
    • 校验和
      为增加可靠性,对TCP头,TCP数据计算校验和
      占16位

    紧急指针

    • 用来指示紧急数据在当前数据段中的位置,是一个相对于当前序列号的字节偏移值。当URG标志置1时紧急指针才有效
    • 占16位
    • 可选项域

    TCP连接建立

    建立过程(注:LISTEN,ACCEPT,CONNECT等就是伯克利套接字原语)
    服务器方执行LISTEN和ACCEPT原语,被动监听
    客户方执行CONNECT原语,产生一个SYN为1和ACK为0的TCP段,表示连接请求
    服务器方的传输实体接收到这个TCP段后,首先检查是否有服务进程在所请求的端口上监听,若没有,回答RST置位的TCP段
    若有服务进程在所请求的端口上监听,该服务进程可以决定是否接受该请求。在接受后,发出一个SYN置1和ACK置1的TCP段表示连接确认,并请求与对方的连接
    发起方收到确认后,发出一个SYN置0和ACK置1的TCP段表示给对方的连接确认
    若两个主机同时试图建立彼此间的连接,则只能建立一条连接

    TCP连接释放

    在数据传输结束后,通信的双方都可以发出释放连接的请求
    释放过程对每个单工连接单独释放
    TCP连接释放,释放连接时,发出FIN位置1的TCP段并启动定时器,在收到确认后关闭连接。若无确认并且超时,也关闭连接

    TCP连接的管理模型

    粗实线:客户的正常路径
    粗虚线:服务器的正常路径
    细线:不正常的事件
    事件/动作:
    事件或者是用户发起的系统调用(CONNECT、LISTEN、SEND或CLOSE),或者是一个数据段的到达(SYN、FIN、ACK或RST),或者是两倍最大分组生存期的超时事件。
    动作是发送一个控制数据段(SYN、FIN或RST)

    TCP传输策略

    TCP的窗口管理机制
    基于确认和可变窗口大小
    窗口大小为0时,正常情况下,发送方不能再发TCP段,但有两个例外,紧急数据可以发送,为防止死锁,发送方可以发送1字节的TCP段,以便让接收方重新声明确认号和窗口大小

    策略1:发送方缓存应用程序的数据,等到形成一个比较大的段再发出

    策略2:在没有可能进行“捎带”的情况下,接收方延迟(如:延迟500ms)发送确认段和窗口更新

    策略3: Nagle算法
    若数据是逐个字节地到达发送端,那么发送端就将第一个字符先发送出去,将后面到达的字符都缓存起来
    当收到第一个字符的确认后,再将缓冲区中的所有字符(装成)用一个TCP数据段发送出去,同时继续对到达的字符进行缓存
    只有在收到确认后才继续发送下一个数据段
    如果传递进来的数据足够多,多到可以填充一半窗口或填满一个最大数据段长度时,该算法允许发送一个新的数据段

    策略4:使用Clark算法解决傻窗口症状
    傻窗口症状

    设想这种情况,接收端的缓冲区已满,而接收方的应用程序每次只从缓冲区中读取一个字节时,传输层实体会产生一个一字节的窗口更新段,使得发送方只能发送一个字节
    解决办法
    限制接收方只有在具备一半的空缓存或最大段长的空缓存时,才产生一个窗口更新段
    Nagle算法和Clark针对傻窗口症状的解决方案时相互补充的
    发送方不要发送太小的数据段(Nagle)
    接收方不要请求太小的数据段(Clark)

    TCP的拥塞控制

    TCP认为导致网络拥塞的两个潜在因素
    接收方接收能力
    网络传输能力

    TCP处理因接收方接收能力和网络传输能力而采取的措施
    发送方维护两个窗口:接收方准许的窗口和拥塞窗口
    允许发送的字节数量是这两个窗口的最小值

    在TCP中使用窗口的概念

    接收方准许的窗口(通知窗口)
    接收方根据其能力许诺的窗口值
    是来自接收端的流量控制
    接收端将此窗口值放在TCP报文的头部中,传送给发送端

    慢启动(slow start)算法

    连接建立时,发送方将拥塞窗口初始化为该连接允许的最大数据段长(如1KB)
    发出一个最大段长的TCP段,若正确确认,拥塞窗口变为两个最大数据段长
    发送出2个最大长度的TCP段,若都得到确认,则拥塞窗口再加倍
    重复上一步,拥塞窗口一直呈指数增加,直至发生丢包超时事件或拥塞窗口达到接收方窗口大小

    因特网的拥塞控制算法


    最大的数据段长度为1KB;
    初始时阈值为64KB;
    图是发生一次超时后,阈值被设置为32KB,拥塞窗口被设置为1KB(对应0号传输)

    阈值初始时为64KB,当第一次超时发生时,阈值被设置为当前拥塞窗口的一半;而拥塞窗口初始化为该连接允许的最大数据段长
    使用慢启动算法来决定网络的处理能力,当增长到阈值时停止
    从这点开始,每次成功的传输都会使拥塞窗口线性增长

    有效窗口是发送方和接收方分别认为合适窗口中最小的那个

    在未发生拥塞的稳定工作状态下,两个窗口(接收方准许的窗口和拥塞窗口)是一致的

  • 相关阅读:
    WCF如何通过契约加编码方式调用
    编码为multipart/form-data自定义类型(包括文件)如何自动绑定到webapi的action的参数里
    MSMQ消息队列
    使用windows服务和MSMQ和进行日志管理(解决高并发问题)
    二叉树的三种遍历方式
    go语言的3个包——strconv、os.Args、flag
    公钥、私钥、签名、数字证书的关系
    go语言实现单链表
    Go语言学习笔记(10)——错误处理示例
    go语言实现链式栈
  • 原文地址:https://www.cnblogs.com/mengxiaoleng/p/11951770.html
Copyright © 2011-2022 走看看