传输层协议总结----TCP和UDP

参考:公众号小林coding
一.TCP/IP架构
TCP/IP协议族按层次分别为 应用层,传输层,网络层,数据链路层,物理层

\color{blue}{应用层}的任务是通过应用进程之间的交互来完成特定网络应用。应用层的协议定义的是应用进程间通信和交互的规则。应用层的协议主要有:域名系统DNS, 支持万维网应用的HTTP协议,支持电子邮件的STMP协议等。
\color{blue}{运输层}的主要任务是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。
\color{blue}{网络层}的任务是在进行通信的两个计算机之间选择合适的网间路由和交换结点,确保数据及时传送。在发送数据时,网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。
\color{blue}{数据链路层}在两个相邻节点之间传送数据时,数据链路层将网络层交下来的 IP 数据报组装成帧,在两个相邻节点间的链路上传送帧
\color{blue}{物理层}的作用是实现相邻计算机节点之间比特流的透明传送,尽可能屏蔽掉具体传输介质和物理设备的差异

二、TCP和UDP的头部格式


TCP头部格式.png

从图中可以看出不包括选项部分,TCP的固定头部长度为20B.而正是因为其存在选项部分,其首部长度不固定所以在其头部存在4B的首部长度字段。

\color{blue}{序列号}:用来解决网络包乱序问题。其在建立连接时由计算机生成的随机数作为其初始值,每发送一次数据,就累加一次该数据字节数的大小。

\color{blue}{确认应答号}:用来解决不丢包的问题。指下一次期望收到数据的序列号,发送端收到这个确认应答以后可以认为在这个序号一起的数据都已经被正常接收。

UDP头部格式.png

从上图可以看出UDP的固定头部长度为8B

三、为什么需要TCP协议?
因为TCP协议所在的下层IP层是不可靠的。它不保证网络包的交付,不保证网络包的按序交付,也不保证网络包中的数据的完整性。所以如果需要保障网络数据包的可靠性,那么就需要由上层的TCP协议来负责。

四、什么是TCP\color{blue}{连接}
TCP连接不是一个物理连接而是一个逻辑连接。它是用于保证可靠性和流量控制维护的某些状态信息,这些信息的组合包括Socket,序列号和窗口大小称为连接

五、TCP和UDP的区别:
1.TCP的头部信息比较丰富,固定首部长度达到20B,而UDP的固定首部长度为8B
2.UDP是一种不可靠的传输协议,不需要建立连接,不需要进行确认,数据是否丢失也不会被发现重传,所以它支持一对一,一对多、多对多的交互通信。当数据到达的时候能够及时传输。
TCP是面向连接的传输层协议,所以它只能进行一对一的交互通信并且在传输数据前先要通过三次握手建立连接,在结束传输时需要通过四次挥手断开连接。 其次TCP有拥塞控制和流量控制机制,保证数据传输的安全性。
3.UDP传输报文方式由应用程序控制,应用层交给UDP多长的报文UDP照样发送,既不拆封也不合并保留报文的边界。
TCP是面向字节流的,它是以字节流的形式传递给接收者,没有边界的概念每个TCP会有一个发送缓冲区,如果字节流太长,TCP会将其拆分,然后再发送;当字节流太短,TCP会等待缓冲区中字节流到合适的时机再发送出去。

\color{blue}{TCP和UDP应用场景}
由于TCP是面向连接,能保证数据的可靠性交付,因此它适合数据完整性通信质量要求高的场景,比较适合文件下载(FTP文件传输),浏览网页(HTTP/HTTPS)等。
由于UDP面向无连接,它可以随时发送数据并且UDP本身的处理简单高效因此经常用于:视频,音频等多媒体通信

六、TCP三次握手过程和状态变迁


状态变迁.png

一开始,客户端和服务器都处于CLOSED状态。先是服务器主动监听某个端口,处于LISTEN转态
第一握手由客户端发起,客户端会随机初始化序号(client_isn)并向服务端发送一个报文,在报文中SYN标志位为1,之后客户端处于SYN-SENT状态。服务端收到这个报文之后就知道客户端要发起一个新的连接,于是服务端也会随机初始化自己的序列号(sever_isn),其次把确认应答号设置为客户端发来的序号client_isn+1,接着把SYN和ACK标志为置1。最后把该报文发给客户端。之后服务端处于SYN-RCVD状态。
客户端收到服务端报文后,还要向服务端回应最后一个应答报文,首先该应答报文ACK标志位为1并且确认序列号为服务端发来报文序列号sever_isn+1,最后把报文发送给服务端,注意:这次报文是可以携带客户到服务器的数据,之后客户端处于ESTABLISHED状态。服务器收到客户端的应答报文后,也进入ESTABLISHED状态。

\color{red}{从上面的过程可以发现第三次握手是可以携带数据的,前两次握手是不可以携带数据的}

TCP四次挥手过程和状态变化

四次挥手.png

1.当客户端打算关闭连接,此时会发送一个TCP首部FIN标志位被置为1的报文,之后客户端进入FIN_WAIT_1状态
2.服务端收到该报文后,就向客户端发送ACK应答报文,接着服务端进入CLOSED_WAIT状态
3.客户端收到服务端的ACK应答报文后,之后进入FIN_WAIT_2状态
4.客户端收到服务端的FIN报文后,回一个ACK应答报文,之后进入TIME_WAIT状态
5.服务器收到ACK应答报文后,就进入CLOSE状态,至此服务端以及完成连接的关闭
6.客户端在经过2MSL一段时间后,自动进入CLOSE状态,至此客户端也完成连接的关闭
从上述步骤可以看出,无论是客户端还是服务端都需要\color{blue}{一个FIN和一个ACK,因此被称为四次挥手}
注意:主动关闭连接的,才有\color{blue}{TIME\_WAIT状态}

七、为什么需要三次握手和四次挥手
\color{blue}{三次握手的目的}
1.为了避免旧的重复连接初始化的影响
比如如果客户端发送了多次请求连接,由于网络堵塞,可能旧的连接请求比最新的连接请求先到达,那么服务端会发送一个确认报文给客户端。客户端收到后可以根据自身的上下文(比较确认报文中的确认号和发送的序列号),判断这是一个历史连接,如果是历史连接,则第三次握手发送的报文是请求终止报文RST;如果不是历史连接,则第三次发送的报文是ACK报文,通信双方就会处于成功建立状态。

2.同步双方初始序列号
当客户端发送携带初始序列号的请求连接报文的时候,需要服务端回一个ACK应答报文,表示客户端的请求连接报文已被服务端成功接收,那当服务端发送初始序列号给客户端的时候,依然也要得到客户端的应答回应,这样一来一回,才能确保双方的初始序列号被可靠的同步。

3.避免资源的浪费
如果只有两次握手,当客户端发送了多次连接请求,由于没有第三次握手,服务器不清楚客户端是否收到了自己发送的建立连接的ACK确认序号,所以每收到一个SYN就只能先主动建立一个连接,这样会导致建立多个冗余的无效链接,造成不必要的资源浪费。

\color{blue}{为什么挥手需要四次?}
关闭连接时,客户端向服务端发送结束报文时,仅仅表示客户端不再发送数据了,但是还能接收数据。
服务器收到客户端的FIN报文时,先回一个ACK应答报文,而服务端可能还有数据需要处理和发送,等服务端不再发送数据时,才发送FIN报文给客户端来表示同意现在关闭连接。
从上面的过程可知,服务端通常需要等待完成数据的发送和处理,所以服务端的ACK和FIN一般都会分开发送,从而比三次握手导致多了一次。

八、为什么TIME_WAIT等待的时间是2MSL?
MSL是Maximum Segment Lifetime,报文最大生存时间
2MSL的时间是从客户端收到FIN后发送ACK报文开始计时的。如果在TIME-WAIT时间内,因为客户端的ACK没有传输到服务端,客户端又接收到了服务端重发的FIN报文,那么2MSL时间将重新计时。

九、总结什么是TCP协议和UDP协议以及应用场景?
TCP协议是面向连接的安全可靠的数据传输协议。它需要经过三次握手和对方确立连接关系之后才可以进行信息传输并且在断开连接的时候需要经过四次挥手,除此之外,tcp还有超时重传机制,滑动窗口,流量控制等一系列技术,保证数据在传输过程中不会出现丢失,乱序等情况。因此tcp适合数据完整性通信质量要求高的场景,比如:适合文件下载,浏览网页等。

UDP协议是一种不可靠的传输层协议,不需要建立连接,不需要进行确认,数据是否丢失也不会被发现重传。也正是因为UDP面向无连接,它可以随时发送数据并且UDP本身的处理简单高效因此它可以进行单播,组播以及多播传输数据。经常用于视频,音频这样的多媒体通信。

十、什么是超时重传
\color{blue}{重传机制}就是客户端在发送数据时,会设定一个定时器,当超过指定的时间后没有收到对方的ACK确认应答报文,就会重发该数据。

TCP会在以下两种情况发送超时重传:
1.数据包丢失
2.确认应答丢失

重传机制中存在超时重传,快速重传以及选择性确认机制。
快速重传:发送方收到了三次同样的ACK确认报文,于是就会触发快速重发机制。但是这种机制存在一个缺陷是:\color{blue}{重传的时候,是重传之前的一个,还是重传所有的问题。}比如说发送seq1,seq2,seq3,seq4,seq5假设seq2丢失了会发送三个ack2的报文,但现在存在一个问题是是重传 Seq2 呢?还是重传 Seq2、Seq3、Seq4、Seq5 呢?因为发送端并不清楚这连续的三个 Ack 2 是谁传回来的。

选择确认机制在 TCP 头部「选项」字段里加一个 SACK 的东西,它可以将缓存的地图发送给发送方,这样发送方就可以知道哪些数据收到了,哪些数据没收到,知道了这些信息,就可以只重传丢失的数据。

十一、滑动窗口和流量控制
TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率,保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。

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

推荐阅读更多精彩内容