唯倚社区

 找回密码
 立即注册

QQ登录

只需一步,快速开始

搜索
查看: 586|回复: 5

计算机网络中的TCP/UDP协议到底是怎么回事(一)

[复制链接]

27

主题

142

帖子

522

积分

版主

Rank: 7Rank: 7Rank: 7

积分
522
发表于 2017-9-13 15:44:34 | 显示全部楼层 |阅读模式

轻松玩转社区

您需要 登录 才可以下载或查看,没有帐号?立即注册

x


                                                                                                                            文/Martin_wjl(简书作者)原文链接:http://www.jianshu.com/p/8be9b3204864TCP/IP五层网络结构模型
  • 物理层:物理层建立在物理通信介质的基础上,作为系统和通信介质的接口,用来实现数据链路实体间透明的比特 (bit) 流传输。只有该层为真实物理通信,其它各层为虚拟通信
  • 数据链路层:在物理层提供比特流服务的基础上,建立相邻结点之间的数据链路,通过差错控制提供数据帧(Frame)在信道上无差错的传输,并进行各电路上的动作系列。数据的单位称为帧(frame)
  • 网络层:选择合适的路由,使数据分组(packet)可以交付到目的主机
  • 传输层:负责主机中进程间的通信
  • 应用层:直接为用户的应用程序提供服务

用图说话:

传输层
我们知道传输层是在进程间传输报文,同时TCP协议、UDP协议是TCP/IP中最具有代表性的传输层协议。下面就总结一下两个协议的异同以及传输层的工作原理。
TCP与UDP区分:
TCP协议:面向连接、可靠的流协议。连接是指两个应用程序为了相互传递信息而专有的、虚拟的通信线路,也叫做虚拟电路。流是指不间断的数据结构,类似于管道中的水流。可靠性指TCP协议提供可靠性传输,实行“顺序控制”或“重发控制”机制。此外还具有“流量控制”、“拥塞控制”提供网络利用率等众多功能。
UDP协议:不具有可靠性的数据报协议。只确保发送消息,其他处理都由上层应用来完成。
哇!TCP这么多特点,是不是一定比UDP厉害呢?其实不然,他们各有自己的应用场景。
TCP应用场景:效率要求相对低,但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作,相比之下效率没有UDP高。举几个例子:文件传输(准确高要求高、但是速度可以相对慢)、接受邮件、远程登录。
UDP应用场景:效率要求相对高,对准确性要求相对低的场景。举几个例子:QQ聊天、在线视频、网络语音电话(即时通讯,速度要求高,但是出现偶尔断续不是太大问题,并且此处完全不可以使用重发机制)、广播通信(广播、多播)。
传输通信:
两个协议是进程间通信,也就是说应用间的通信,那么如何在众多程序中找到自己的目的应用呢?在传输层,使用端口号来识别同一台计算机中进行通信的不同应用程序。
一般情况下可以根据“源IP地址”、“目标IP地址”、“源端口号”、“目标端口号”来进行识别一个通信,但是有些特殊情况,比如IP地址和端口号都一样,只是使用的传输协议不一样,怎么进行区分?数据到达IP层(网络层)之后,会先检查IP头部的协议号,然后再传给相应协议的模块。
因此,TCP/IP或UDP/IP通信中通常使用5个信息来识别一个通信:“源IP地址”、“目标IP地址”、“源端口号”、“目标端口号”以及“协议号”。(知名端口号与传输层协议没有关系,例如53端口在TCP、UDP中都用于DNS服务)
端口号如何确定:标准既定的端口号,0-1023为知名端口号,其他已正式注册的端口号是1024-49151;动态分配端口号,操作系统来为应用程序分配互不冲突的端口号,下一个端口号是在前一个分配号上加1,动态分配端口号范围49152-65535.
UDP详解
UDP是User Datagram Protocol缩写。UDP不提供复杂的控制机制,利用IP提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻,立即按照原样发送到网络上的一种机制。
UDP为何存在?有哪些优点呢?
  • 无需建立连接(减少延迟)
  • 实现简单:无需维护连接状态
  • 头部开销小
  • 没有拥塞控制:应用可以更好的控制发送时间和发送速率
UDP头部:

UDP的头部是由源端口号、目标端口号、包长和校验和组成。checksum主要是用来检测UDP段在传输中是否发生了错误。还有就是,校验和计算中也需要计算UDP伪头部,伪头部包含IP头部的一些字段。我们刚才介绍了识别一个通信需要5项信息,而UDP头部只有端口号,余下的三项在IP头部,所以引入了伪头部的概念。(IPv6的IP头部没有校验和字段)

目前有一些场景需要兼顾可靠性和高效性,那么如何在UDP上实现可靠数据传输呢?
TCP详解
TCP通过校验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。
连接管理:
数据通信之前必须先做好连接工作,在TCP中连接的建立需要三次握手,同时在通信结束时会进行断开连接的处理(四次挥手)。一个连接的建立与断开,正常过程至少需要来回送7个包才能完成。

在TCP中,当发送端的数据到达主机时,接收端主机会返回一个已收到消息的通知,这个消息叫ACK(确认应答,Positive Acknowledgement)。如果没有收到ACK,那么很可能出现了丢包或者返回的确认在途中丢失,此外,也可能是由于其他原因,ACK延迟到达。发送方没有收到ACK的话就会进行重发,但是针对延迟和ACK丢失的情况,会存在重复发送和接收。于是我们就引入了一种机制,来识别是否已经接收数据,又能识别是否已经接收。
上述重复控制的功能可以通过序列号来实现。序列号是按照顺序给发送数据的每一个字节都标上号码的编号,接收端查询接收数据TCP首部中的序列号和数据的长度,将自己下一步应该接收的 序号作为确认应答号返送回去。通过序列号和确认应答号,TCP实现可靠传输。

利用窗口控制提高速度
如果我们每发送一个段就进行一次确认,那么包的往返时间越长,网络的吞吐量量就会越差,通信性能就会越低。
为了解决这个问题,TCP引入了窗口的概念。确认应答不再是以每个片段,而是以更大的单位(窗口大小)进行确认,转发时间就被大幅度的缩短。至于窗口的大小是由接收端主机决定的,也方便进行流控制。
窗口控制与重发控制
允许发送方在收到ACK之前连续发送多个分组,针对段丢失的情况,我们来讨论窗口控制。
针对以前的延迟ACK,使用窗口控制之后,可以收到确认应答之前继续发送报文,这样整体速度就大大提高。
针对确认应答未能返回的情况。没有使用窗口控制的时候,没有收到确认应答的数据都会被重发,而使用了窗口控制,某些确认应答即便丢失也无需重发。可以根据自己的确认应答或者下一个确认应答来确认。

针对报文段丢失的情况。当一个报文丢失时,发送端会连续收到多个序号为1001的确认应答,来提醒发送端再次发送报文。对于发送端,如果连续三次收到同一个确认应答,将会对其对应的数据进行重发。





                    
                        

来源地址:http://mp.weixin.qq.com/s?src=3×tamp=1492929673&ver=1&signature=nKb9TTAHEsCT3T3eDwApOywixIUC1wsIkRWyAAtz5j41UTCV4rwny21JQMf2qpBScTahRKbgXEY1cAyM1sFtsmbi7RCi53JYDgkWu7QLBN3F732PFls2ebsOtZPlCsV31BJU*B5HJEKbuj5j4X-b9w==

3

主题

122

帖子

426

积分

版主

Rank: 7Rank: 7Rank: 7

积分
426
发表于 2017-9-23 00:15:31 | 显示全部楼层
楼主快去捡肥皂吧
回复

使用道具 举报

3

主题

122

帖子

426

积分

版主

Rank: 7Rank: 7Rank: 7

积分
426
发表于 2017-9-23 00:35:31 | 显示全部楼层
长得帅的才有青春,像我们这样的只有大学了
回复

使用道具 举报

137

主题

308

帖子

3832

积分

LV3

Rank: 3Rank: 3

积分
3832

最佳新人

发表于 2017-9-23 08:56:50 | 显示全部楼层
火钳刘明
回复

使用道具 举报

1

主题

22

帖子

270

积分

VIP

积分
270
发表于 2017-9-23 10:56:53 | 显示全部楼层
会不会成热贴啊,我写的这么好会不会太招遥,写的这么深奥别人会不会看不懂啊,怎样才能写出我博士后的水平呢,半年写了这么多会不会太快啊,好激动啊
回复

使用道具 举报

33

主题

160

帖子

434

积分

版主

Rank: 7Rank: 7Rank: 7

积分
434
发表于 2017-9-23 11:08:06 | 显示全部楼层
我只是挽尊的,貌似还不够十五字
回复

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

手机版|小黑屋|weiecn ( 湘ICP备14002058号 )

GMT+8, 2018-12-17 17:53 , Processed in 0.059715 second(s), 9 queries , Redis On.

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表