Android面试必备佳品之TCP与UDP协议

在面试的时候我们经常会被问道有关计算机网络相关的内容,尤其是TCP与UDP,它的登场率可以说是相当高了。这部分内容是基础并且很重要。所以我们有必要好好的学习一下它。即使不为了面试这也是值得去学习的知识点,因为说不定哪天你就用上它了哈。

一、TCP和UDP的区别

一般我们都会被问到这两个协议的区别,大部分人会回答,TCP 是面向连接的,UDP 是面向无连接的。

那么什么叫面向连接,什么叫无连接呢?

在互通之前,面向连接的协议会先建立连接。所谓的建立连接,是为了在客户端和服务端维护连接,而建立一定的数据结构来维护双方交互的状态,用这样的数据结构来保证所谓的面向连接的特性。
比如我们的TCP协议,它会通过三次握手建立连接。而我们的UDP就不需要建立连接。正因为这样的不同,才有了两者各自不同的特点:

TCP和UDP的特点

1.TCP提供可靠交付、通过TCP连接传输的数据,无差错不丢失、不重复、并且按序到达。但是UDP继承了IP包的特性,不保证不丢失和按顺序到达。

2.TCP是面向字节流的,发送的时候是个流,没有头和尾。但是UDP继承了IP包的特性,面向数据报,一个一个的发送,一个一个的收。

3.TCP还可以进行拥塞控制,可以根据情况调控发送的速度。但是UDP不会,应用让它发就发,发出去就不管它的事了。

简单总结一下就是,TCP有脑子的,它会记录发送的情况,接收的情况,还可以控制发送过程,无疑这是很可靠。不像UDP一样,没有脑子,发出去就发出去了,之后就什么也不管了。当然这也不能怪它,毕竟它是继承了它的父亲IP的基因,几乎没有自己的思想。

这样说的好像UDP一无是处一样,其实我们都知道一个缺点换个角度看它很有可能就会变成优点。所以下面我们先详细认识一下这个UDP。

二、UDP

1.先看一下UDP的包头
udp.jpg

可以看出UDP的包头很简单,为什么这么说它简单呢?因为和TCP的包头比较一下就会发现,它是真的超级简单【没有对比就没有伤害,滑稽笑】

发送UDP数据包,发送者是知道的,但是接收者是怎么知道是UDP包的呢?这就需要靠IP头里的8位协议,它里面会存放表示是TCP或者是UDP的信息。这里当然就是UDP了。

之后接收者会将它解析出来,然后把数据发送给应用程序正在监听的端口。那发送给哪个端口呢?

这时候UDP包头的作用就开始凸显了,由于是两端通信,所以它携带了源端口号和目的端口号,通过目的端口号,就可以把包准确的发送给应用程序了。

2.UDP的特性

从这个过程可以看出来,UDP的传输很简单

1.它不会建立连接,只是通过端口号来发送和传输数据,谁都可以传给他,它也可以传输给任何人甚至同时传输给一群人。
2.它相信包不会在传输的过程中丢失,也不会根据网络情况进行拥塞控制。
3.UDP简单、处理速度快,不像TCP一样需要操很多心,考虑各种重传、保证顺序、前面的收不到等等。

3.UDP适用场景

正是因为这些特点所以它适合在这样一些场景

(1)需要资源少,对丢包不敏感、网络比较好的应用。
DHCP 就是基于 UDP 协议的。一般的获取 IP 地址都都是内网请求,而且一次获取不到 IP 又没事,过一会还有机会。

(2)不需要一对一连接和沟通,可以广播的应用。
DHCP就是一种广播的方式。

(3)需要处理速度快、可以容忍少数丢包,但是要求即便网络堵塞也毫不退缩,勇往直前的时候。

这个时候TCP就不合适了。因为TCP在网络不好出现丢包的时候,拥塞控制策略会主动的退缩,降低发送速度,这就相当于本来环境就差,我还降低速度,那岂不是会卡到吐血,不能忍。

譬如说

现在的很火的直播应用,很多都是基于 UDP 实现了自己的视频传输协议。因为用户要看的是最新的内容,宁愿看丢失几帧的视频也不会愿意看卡出翔的视频。但是TCP的严格顺序传输要保证前一个收到了,下一个才能确认,如果前一个收不到,下一个就算包已经收到了,它也会被放到缓存里面,一直等着。对于直播来讲,这显然是不合适的,因为老的视频帧丢了其实也就丢了,就算再传过来用户也不在意了,他们要看新的内容。即使过程会丢包,丢了几帧那影响也不大,看视频的人不会有很明显的感知。

三、TCP

前面说了TCP的包头没有UDP那么简单了,那它是什么样子的呢?

a.jpg
1.认识包头

(1)我们可以看到最上层和UDP的一样,都是源端口号和目的端口号。如果没有这两个端口号。数据就不知道应该发给哪个应用。所以这是必不可少的。

(2)接下来就是包的序号。为什么要给包编号呢?这是为了解决后面的乱序问题,不编号好号接收方怎么确认哪个应该先来哪个后到呢。可能这里不能很好的理解。看完后面的内容就会清楚了。

(3)之后就是确认序号。发出去的包要有确认,要不然我不知道对方有没有接收到的,可能以为丢包了,就会不断重发这个包,所以需要有个确认序号。

(4)接下来就是一些状态位:SYN表示发起一个连接,ACK是回复,RST是重新连接,FIN是结束连接。

TCP 是面向连接的,因而双方要维护连接的状态,这些带状态位的包的发送,会引起双方的状态变更。这些状态位要记住,这对我们后面要说的面试常问问题《TCP的三次握手和四次挥手》很重要。

(5)最后还有一个重要的是窗口大小,TCP要做到流量控制和拥塞控制,通信的双方就会声明一个窗口,表明自己的处理数据能力。通过这个窗口大小就可以控制发送的速度了。

通过对包头的认识,可能总结以下TCP的特点:

可以维护连接、保证发送包的顺序、保证结果不会丢包(过程可能会丢包,但会通过重传机制保证结果不会丢包),还可以进行流量控制、拥塞控制

四、面试问题之三次握手

TCP为什么要三次握手,而不是两次握手,四次握手?

1.A和B的连接过程,三次握手最主要是防止已过期的连接再次传到被连接的主机
如果采用两次的话,可能会出现下面这种情况。
比如是A要连接到B,结果发送的连接信息由于某种原因没有到达B;
于是,A又发了一次,结果这次B收到了,于是就发信息回来,两机就连接。当它们通信完断开后。这时候,原先没有到达的连接信息突然又传到了B,于是B发确认连接给A,然后B机就以为和A连上了,这个时候B就开始等待A传东西过去。

其实四次握手、四百次握手也是可以的,但只需要三次握手就可以实现A和B的连接,四次握手和三次握手的效果是一样的,所以不需要进行多余的握手操作。

2.在建立连接的时候要考虑一个问题,就是TCP包的序号

A要告诉B,我这面发起的包的序号起始是从哪个号开始的, B同样也要告诉A, B发起的包的序号起始是从哪个号开始的。为什么序号不能都从1开始呢?因为这样往往会出现冲突。
例如,A连上B之后,发送了1、2、3三个包,但是发送3的时候,中间丢了或者绕路了,于是重新发送,后来A掉线了,重新连上B后,序号又从1开始,然后发送2,但是压根没想发送3,但是上次绕路的那个3又回来了,发给了B, B自然认为这就是下一个包,于是发生了错误。因而,每个连接都要有不同的序号。

建立连接后,为了维护这样一个连接,需要双方维护一个状态机。在连接建立的过程中,双方的状态变化时序图如下:

tcp2.jpg

【状态位:SYN表示发起一个连接,ACK是回复,RST是重新连接,FIN是结束连接】

(1)一开始,服务端处于监听某个端口的状态,然后客户端发起主动连接SYN,之后处于SYN-SENT状态。

(2)服务端收到发起的连接,返回SYN,并且ACK客户端的SYN,之后处于SYN-RCVD状态。

(3)客户端收到服务端发送的SYN和ACK之后,发送ACK的ACK,之后处于 ESTABLISHED 状态,因为它一发一收成功了,服务端收到ACK的ACK后,也处于 ESTABLISHED 状态。这样就建立好了双方的连接。

五、面试问题之四次挥手

TCP为什么要进行四次挥手?关闭连接一应一答,两次不就可以了?

A发送给B发消息说我要关闭连接了,但是B能不能在ACK的时候就关闭连接呢?这是不可以的,因为A发完了数据要关闭与B的连接,但是B很有可能没有做完自己的事情,还要发送数据呢,此时称为半关闭状态。

这个时候A可以选择不接收数据,也可以选择最后再接收一段数据,等待B的关闭。这样整个连接就关闭了。

过程类似这样:

小明:小花,我要走了

小花:哦,我知道了(还剩一堆话说要和小明说)balabala

小花:好的,你走吧,白白

小明:好的,白白

上面是比较和平的分手情况。但是有可能会出现这种异常的情况,A发消息"我要走了",因为B还没有结束任务,就不会回复关闭的消息,此时由于A没有收到消息,就会以为我没有把消息成功发过去,就会重新发送消息“我走了”。

还有一种就是A发完消息有一方直接跑路的,A跑路,B即使发起结束也得不到回答,B就不知道怎么办了;或者B跑路,A不知道B是结束了还是目前正在处理自己的事情待会才发起结束,A就不知道怎么办了。所以两次挥手就会有很多问题,就需要四次挥手。

对于这些问题,TCP协议设计了几个状态来处理这些问题,我们看一下关闭连接的状态时序图。

tcp3.jpg

(1)开始,客户端先发送关闭连接的消息,然后处于 FIN_WAIT_1 的状态。

(2)服务端接收到消息后,发送收到关闭连接的消息后,就处于CLOSE_WAIT 的状态,此时服务端继续处理未做完的事情。

(3)服务端处理完所有事情后,发送确认关闭的消息。

(4)客户端接收到确认关闭的消息再给予ACK。这样A和B就会成功的关闭连接了。

到这里相信你对这两个协议有了个相对较深的理解,在面试的时候被问到这类问题肯定可以游刃有余的回答,能够得到面试官的会心一笑,嘻嘻。

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