计网之传输层

UDP TCP
全称 用户数据报协议 传输控制协议
英文 User Datagram Protocol Transmission Contorl Protocol
不需要先建立连接 提供面向连接的服务
面向报文的 面向字节流的
应用 应用层协议 运输层协议
名字转换 DNS 域名系统 UDP
文件传送 TFTP 简单文件传送协议 UDP
路由选择协议 RIP 路由信息协议 UDP
IP地址配置 DHCP 动态主机配置协议 UDP
网络管理 SNMP 简单网络管理协议 UDP
IP电话 专用协议 UDP
流式多媒体通信 专用协议 UDP
多播 IGMP网际管理协议 TCP
电子邮件 SMTP 简单邮件传送协议 TCP
远端终端接入 TELNET 远端终端协议 TCP
万维网 HTTP 超文本传送协议 TCP
文件传送 FTP 文件传送协议 TCP

协议端口号(protocol port number)

协议端口号(protocol port number)简称 端口(port)

  • 16位的端口号可允许65535个不同的端口号
  • 服务器端使用的端口号
    • 熟知端口号(well-konwn port number)(系统端口号)
    • 登记端口号
  • 客户端使用的端口号(短暂端口号)

熟知端口号 0-1023 (www.iana.org) 被分配给TCP/IP最重要的一些应用程序
常用熟知端口号

应用 FTP TELNET SMTP DNS TFTP HTTP SNMP SNMP(trap) HTTPS
端口号 21 23 25 53 69 80 161 162 443

登记端口号 1024-49151 使用必须在IANA登记
客户端使用的端口号 49152-65535

UDP

特点:

  1. 无连接的 发送前无需建立连接
  2. 尽最大努力交付 主机无需维持复杂的连接状态表
  3. 面向报文的 对应用层交下来的报文直接发送
  4. 没有拥塞控制
  5. 支持一对一、一对多、多对一
  6. 首部开销小

    源端口 发送端的端口 需要对方回信时设置否则为零
    长度 UDP数据报的长度 最小值为8字节
    校验和 加上伪首部计算

TCP

特点:

  1. 面向连接的运输层协议 必须先建立连接
  2. 点对点
  3. 可靠交付
  4. 全双工通信
  5. 面向字节流

TCP的端点 —— 套接字socket
套接字 socket = (IP地址:端口号)

TCP理想的传输条件:

  1. 传输信道不产生差错
  2. 不管发送方以多快的速度发送数据,接收方总是来得及处理收到的数据
停止等待协议

停止等待指的是每发送一个分组就停止等待,等待对方的确认

instance1 无差错情况
发送方只有在确认了接收方的确认报文才会继续发送下一条报文


instance2 出现差错

  • 数据报在传输过程中出错了,接收方就丢弃了,然后等待。发送方可以设置一个超时计时器,实现超时重传。
  • 发送方在发送数据报时保存发送的副本,只有等到收到确认报文时才会删除副本。
  • 对数据报分组进行编号

instance3 确认丢失和确认迟到

  • 接收方收到重复的数据报分组就丢弃并发送确认
  • 发送方收到迟到的确认数据报就丢弃并发送下一条
  • 以上第三点称为自动重传请求ARQ(Automatic Repeat reQuest)

instance4 信道利用率

  • 信道利用率=发送分组所需时间 / (发送分组所需时间+RTT+发回确认所需时间)
    此处RTT往返时间即数据报从一端到一端的传输时间
  • 一般情况下发送分组所需时间是小于发送时间的,这样信道利用率较低。需要采用流水传输。

连续ARQ协议

内容

  • 发送方维持一个发送窗口,该窗口内的n个分组都可以连续发送出去,无需等待接收方的确认。
  • 发送方每收到一个确认,就将发送窗口向前滑动一个分组的位置。
  • 接收方采用累计确认的方式,只需返回按序的最后一个分组的确认信息。

TCP报文

  • 序号 本报文段所发送数据的第一个字节的序号
    (TCP连接中传送的字节流中的每一个字节都按顺序局编号)
  • 确认号 期待收到对方一个报文段的第一个数据的序号
    (若有确认号N,则到N-1为止的所有数据都已经正确收到)
  • 数据偏移 TCP数据报的起始位置相对数据报的偏移量
  • 保留 置为零
  • 紧急URG(URGent) URG=1 表示TCP中含有紧急数据
  • 确认ACK(ACKnowledgment) ACK=1 确认号有效
  • 推送PSH(PuSH) PUS=1 发送端立马发送一个报文催促接收端立马交付接收应用进程
  • 复位SYN(SYNchronization) SYN=1&&ACK=0 表示这是一个请求连接的报文段。若对方同意建立连接则SYN=1&&ACK=1
  • 终止FIN(FINis) FIN=1 表示发送端已经发送完毕,要求释放运输连接
  • 窗口 发送本报文一方的接收窗口 若窗口值为N,则告诉对方可接收的范围是[ 确认号,确认号+N]
  • 紧急指针 指出紧急数据末尾在报文中的位置
  • 选项 可变 最大值为40byte

选项:

  • 最大报文长度MSS(Maximum Segment Size) TCP报文段数据字段的最大长度,默认值为536byte
    设置的原因:
    • TCP的首部加上IP的首部至少40byte,若TCP的数据部分很小的话,网络利用率就低了。
    • 若TCP报文段非常长,分解和合并就需要很大的开销
  • 窗口扩大 扩大窗口的范围
  • 时间戳 计算往返时间RTT 发送和确认时记录计算
  • 选择确认

超时重传的自适应算法

报文段的往返时间RTT 收到报文确认的时间减去相应报文的发出时间
加权平均往返时间RTTs(平滑的往返时间)
RTTs初始值为RTT,经过每次测量:
新的RTTs = (1-α) x (旧的RTTs)+ α x(新的RTT样本)

  • 当α比较小时,RTT值更新较慢
  • 当α比较大时,RTT更新较快
  • α建议值为0.125

超时重传时间RTO(Retransmission Time-Out)
RTRd初始值为RTT/2
RTO = RTTs + 4 x RTTd
新的RTTd=(1-β) x (旧的RTTd) + β x |RTTs - 新的RTT样本)
β推荐值为0.25

Question:如何判断某确认报文段是对先前发送的报文的确认,还是对后来重传的报文段的确认?

  • 若收到的确认报文是对重传报文的确认,但是被源主机当作是对原来报文的确认。此时,RTTs、RTO偏大。后续的报文段再发生相同的事,则RTO会越来越长。
  • 同理,相反的会越来越小

Solving: Karn算法

  • 计算加权平均RTTs时,只要报文段重传,就不采用其往返时间样本计算。
  • 报文每重传一次,就把超时重传时间RTO增大一些。如为原来的两倍。

TCP的流量控制

让发送方的发送速率不要太快,让接收方来得及接受
通过设置窗口来进行流量控制

持续计时器
  • 设置原因:假设发送方不被接收方允许发送数据(零窗口通知),此时,接收方告知发送方能够接受数据了(修改窗口大小),告知过程中失败了。发送方在等待接收方的发送通知,而接收方等待发送方发送数据,陷入死循环。
  • 何时启动: TCP连接的一方一收到对方的零窗口通知
  • 运行:当持续计时器到期,发送一个零窗口的探测报文段(1byte),要求对方再返回一个窗口通知

TCP传输效率的提高

Nagle算法 解决数据报段的等待问题

  • 含义:通过减少必须发送包的个数来增加网络软件系统的效率
  • 若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存,则就先发第一个字节的数据,之后的缓存起来统一发送。
  • 步骤:
  1. 应用程序逐字将数据放入TCP发送缓存,将第一个数据字节先发送出去。
  2. 等到该数据字节确认之后再把发送缓存中的所有数据组装成一个报文发出去,同时对随后的数据进行缓存。
  3. 只有在收到对前一个报文段的确认后才继续发送下一个报文段。

模糊窗口综合征(silly window syndrome)

  • 问题的出现条件:
    1.TCP接收方缓存已满
    2.应用程序一次只读1比特,然后向发送方发送确认,并把窗口设置为1比特,紧接着发送发发来1字节的数据,接收方确认。如此循环。
  • 结果:
    网络效率低
  • 解决方案:
    1.让接收方等待一段时间
    2.等到接受缓存已经有一半空闲的空间。

TCP的拥塞控制

拥塞(congestion)
对网络的某一资源的需求超过了该资源所能提供的可用部分
拥塞控制
防止过多的数据注入到网络中,这样可以使网络中的路由器或者链路不致过载。拥塞控制是一个全局性的过程。
流量控制
点对点通信量的控制

TCP拥塞控制的方法

拥塞控制的算法

  1. 慢开始(slow-start)
  2. 拥塞避免(congestion avoidance)
  3. 快重传(fast retransmit)
  4. 快恢复(fast revovery)

Question 如何判断是否发生拥塞?

  1. 出现了超时
  2. 接收到了3个相同的ACK

执行算法时遇到超时,3-ACK,ssthresh/=2 cwnd=1

ssthresh 慢开始门限
SMSS (Sender Maximum Segment Size)最大报文段
cwnd (congestion window) 拥塞窗口 发送方让自己的发送窗口等于拥塞窗口

慢开始
增加原则:拥塞窗口增加量=min(N,SMSS)
    (N为最近一次收到报文的数据量)
特点:每经过一次传播轮次,拥塞窗口cwnd就加倍
停止条件:cwdn > ssthresh

拥塞避免
增加原则:拥塞窗口增加量=1
停止条件:发生拥塞
停止时操作:ssthresh = cwnd/2 cwnd=1

快重传
出现条件:收到连续的3个相同ACK
特点 接收方收到了失序的报文段也要立即发送相应的确认报文(如[M1 M2 M3丢失 M4] 对应的确认报文为 [M1 M2 M2 M2])此时,发送方一连收到3个重复的确认,立刻进行重传,这样就不会出现超时。
转而执行快恢复。

快恢复
cwnd /= 2 即等于 慢开始门限
转而执行拥塞避免

三次握手

  1. 客户端打开连接 发送报文请求 (SYN=1,seq=x)
  2. 服务端收到连接请求 发送确认报文 (SYN=1,ACK=1,seq=y,ack=x+1)
  3. 客户端收到确认后 发送确认的确认报文 (ACK=1,seq=x+1,ack=y+1)

服务端一直处于监听状态

四次挥手

  1. 一方发送连接释放报文 (FIN=1,seq=u)
  2. 另一方收到释放请求 发送确认报文 (ACK=1,seq=v,ack=u+1)
  3. 另一方 再发送连接释放报文 (FIN=1.ACK=1,seq=w,ack=u+1)
  4. 一方发回确认报文 (ACK=1,seq=u+1,ack=w+1)

双方都可以主动关闭连接

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 207,113评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,644评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 153,340评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,449评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,445评论 5 374
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,166评论 1 284
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,442评论 3 401
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,105评论 0 261
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,601评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,066评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,161评论 1 334
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,792评论 4 323
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,351评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,352评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,584评论 1 261
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,618评论 2 355
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,916评论 2 344