您的位置:首页 > 理论基础 > 计算机网络

TCP协议原理与格式初探

2019-05-02 14:45 736 查看

目录

  • 流水线传输
  • TCP解析
  • TCP拥塞控制

    可靠数据传输原理

    如何在一条不可靠的信道上得到可靠的传输?
    不可靠的原因:可能出现比特差错、丢包

    停等传输下的情况

    从简单到难的情况一步步分析:

    1.经过完全可靠信道的可靠数据传输

    这时只需要一发一收,值得注意的是:发送端的发送动作是由上层(应用层)触发,接收端的接收动作是由下层(网络层)触发

    2.经具有比特差错信道的可靠数据传输

    既然可能出现比特差错,那首先要能检测出比特差错,这可以用校验和的方法
    当接收端检测到比特差错,应该向发送端反馈出错了(NAK),发送端再重新发送直到没有错误(即使无错误也要反馈接受无误(ACK)),注意反馈时也要用到校验和
    这里又出现了问题,没有办法保证发送端反馈的信息无差错传输(反馈信息也可能出现错误,表现为校验和错误,不过错误背后的信息即可能是NAK也可能是ACK),因此发送端为了保证万无一失,只要收到的反馈有错误,就重新发送该分组
    然然然而,数据运输是许多个分组,一个接着一个,然后想到如果是ACK分组受损,发送端重传分组,会导致接收端错把重传分组当成新分组,所以必须区分一前一后两个分组,这可以通过在分组前增加0/1来解决(0/1对应一前一后)

    3.经具有比特差错的丢包信道的可靠数据传输

    先考虑丢包的后果,丢包会导致接收端无回应,因此发送端可以选定一个时长,当发送分组在经过此时长后就判定发生丢包,随后重传分组,具体操作是设定一个定时器

    流水线传输

    上面讨论的传输都是停等传输,即发送端收到一个确定,发送一个分组,要想提高效率,可以允许发送端发送多个分组而无需等待确认,一回合发送多个分组后必须要做的工作有:增加序号范围,缓存多个分组,此外对于如何处理丢失、损坏和超时,有两种方法:

    1.回退N步(Go-Back-N,GBN)协议

    发送端:维护一个发送窗口,[Send Base,SendBase+N-1],窗口已满时拒绝上层调用,累计确认ACK(序号n),定时器
    接收端:按序接受,累计确认,丢弃乱序包并反馈
    丢弃一个正确接受的分组的缺点是最后对该分组的重传也许会丢失或出错,因此需要更多的重传

    2.选择重传(Selective Repeat,SR)

    发送端:每个分组一个单独一个定时器,采用单个确认
    接收端:维护一个接收窗口,[rcv_base,rcv_base+N-1],用来缓存失序的分组
    收到序号在小于现在 一个窗口大小范围内 的分组,必须产生一个ACK
    发送端和接收端的窗口并不总是一致,最大错位一个窗口,所以序号范围有限时,为了避免对一个序号的含义混淆(重传/新分组),窗口长度必须小于或等于序号空间大小的一半

    TCP解析

    特点:面向连接的(connection-oriented),全双工服务,点对点的

    TCP报文段结构

    首部一般20字节:源端口号(16bits),目的端口号(16bits),检验和字段(16bits),序号(32bits),确认号(32bits),接收窗口(16bits),首部长度(4bits,以32bits的字为单位),选项(可变长),标志(ACK确认,(RST,SYN,FIN)连接建立与拆除,(CWR,ECE)拥塞报告,PSH(表明应立即将数据交给上层),URG(紧急报文)),紧急数据指针(16bits,配合URG标志使用)
    序号和确认号:序号对数据流中的字节编号,确认号表示下一次接收时期望的序号

    往返时间(Round-Trip Time,RTT)

    往返时间的估计:某个时刻的值SampleRTT,其均值为EstimateRTT
    计算公式:EstimateRTT=(1-α)EstimateRTT+αSampleRTT,α的推荐值为0.125
    (指数加权移动平均)
    偏差的估计:DevRTT=(1-β)DevRTT+β|SampleRTT-EstimateRTT|
    设置和管理重传时间间隔:重传超时间隔TimeoutInterval=EstimateRTT+4*DevRTT,初始值为1s

    TCP可靠数据传输

    这里指出上节可靠数据传输技术的缺点:定时器的管理需要相当大的开销
    拥塞控制的简单方法:超时间隔加倍,初始0.75s
    快速重传:3个冗余ACK--->重传
    累计确认,缓存失序分组

    流量控制(区别于拥塞控制)

    为了消除发送方发送太快,使接收方缓存溢出的可能性
    方法:维护一个接收窗口变量,表明接收方还有多少可用的缓存空间

    TCP连接管理:

    三次握手(客户发起)

    1.客户主机随机生成序号,SYN标志置为1,发送连接请求
    2.服务器随机生成序号,SYN标志置为1,确认号置为客户序号+1,允许连接
    3.客户回复序号+1,SYN置为0,确认号为服务器序号+1,连接建立

    四次挥手(双方都可发起)

    1.一方将FIN标志置为1,请求关闭连接,这一方进入FIN_WAIT_1状态
    2.另一方回复ACK,进入CLOSE_WAIT,(发起方收到ACK,进入FIN_WAIT_2)
    3.并接着回复FIN=1,进入LAST_ACK
    4.初始方收到FIN,回复ACK,进入TIME_WAIT,定时(30s/1min/2min)关闭,(另一方收到ACK,进入CLOSED)

    SYN洪泛攻击的应对

    服务器以请求连接方的IP和Port为参数使用一个私密的散列函数计算出一个值,使其作为服务器初始序号,并发送SYNACK给请求方,这时并不建立半开连接
    如果用户回复ACK,且ACK-1=f(IP,Port),那么说明用户合法,允许建立连接
    如果回复的ACK错误,说明此用户并没有较早的SYN请求,是非法的
    如果没有回复,也不会产生危害,因为服务器并没有给它分配资源

    TCP拥塞控制

    加性增,乘性减(Additive-Increase,Multiplicative-Decrease,AIMD)

    TCP吞吐量

    一条连接的平均吞吐量=0.75W/RTT,W为丢包发生时的窗口长度
    经高带宽路径的平均吞吐量=1.22MSS/(RTT*根号L),L为丢包率

    AIMD算法公平吗

    公平,因为拥塞发生时,原本占带宽大的减少较多的窗口长度,原本占带宽少的减少较少的窗口长度,拥塞避免状态又是以同样速度增加窗口长度,数次拥塞发生后,各连接的窗口长度接近相等,带宽占用趋于平均

  • 内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
    标签: