1夯到、TCP與UDP概述

TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)協(xié)議屬于傳輸層協(xié)議。TCP中文全名：傳輸控制協(xié)議芽唇，UDP中文全名：用戶數(shù)據(jù)報(bào)協(xié)議橄妆。

其中TCP提供IP環(huán)境下的數(shù)據(jù)可靠傳輸翎迁，提供的是面向連接内斯、可靠的字節(jié)流服務(wù)蕴潦。當(dāng)客戶和服務(wù)器彼此交換數(shù)據(jù)前，必須先在雙方之間建立一個(gè)TCP連接俘闯，之后才能傳輸數(shù)據(jù)潭苞。TCP提供超時(shí)重發(fā)，丟棄重復(fù)數(shù)據(jù)真朗，檢驗(yàn)數(shù)據(jù)此疹，流量控制等功能，保證數(shù)據(jù)能從一端傳到另一端遮婶。通俗說秀菱，它是事先為所發(fā)送的數(shù)據(jù)開辟出連接好的通道，然后再進(jìn)行數(shù)據(jù)發(fā)送蹭睡；

而UDP是一個(gè)簡單的面向數(shù)據(jù)報(bào)的運(yùn)輸層協(xié)議，即面向非連接赶么。UDP不提供可靠性肩豁，它只是把應(yīng)用程序傳給IP層的數(shù)據(jù)報(bào)發(fā)送出去，但是并不能保證它們能到達(dá)目的地。由于UDP在傳輸數(shù)據(jù)報(bào)前不用在客戶和服務(wù)器之間建立一個(gè)連接清钥，且沒有超時(shí)重發(fā)等機(jī)制琼锋，故而傳輸速度很快。TCP支持的應(yīng)用協(xié)議主要有：Telnet祟昭、FTP缕坎、SMTP等；UDP支持的應(yīng)用層協(xié)議主要有：NFS（網(wǎng)絡(luò)文件系統(tǒng)）篡悟、SNMP（簡單網(wǎng)絡(luò)管理協(xié)議）谜叹、DNS（主域名稱系統(tǒng)）、TFTP（通用文件傳輸協(xié)議）等搬葬。

在即時(shí)通訊中荷腊，QQ采用UDP結(jié)合TCP、ICQ采用TCP急凰、JABBER基于TCP

備注：什么是面向連接和面向非連接

“面向連接”就是在正式通信前必須要與對(duì)方建立起連接女仰。比如你給別人打電話，必須等線路接通了抡锈、對(duì)方拿起話筒才能相互通話疾忍。

“面向非連接”就是在正式通信前不必與對(duì)方先建立連接，不管對(duì)方狀態(tài)就直接發(fā)送床三。與手機(jī)短信非常相似：你在發(fā)短信的時(shí)候一罩，只需要輸入對(duì)方手機(jī)號(hào)就OK了。

2勿璃、TCP與UDP的區(qū)別

（1）連接方式

TCP：需要建立連接,形成傳輸數(shù)據(jù)的通道

UDP：不需要建立連接,將數(shù)據(jù)源和目的封裝成數(shù)據(jù)包中

（2）數(shù)據(jù)傳輸?shù)拇笮?/p>

TCP：數(shù)據(jù)大小不受限制擒抛，在連接中進(jìn)行大數(shù)據(jù)傳輸

UDP：每個(gè)數(shù)據(jù)報(bào)的大小限制在64K之內(nèi)

（3）安全性

TCP：通過三次握手完成連接，因此是可靠協(xié)議补疑，安全送達(dá)

UDP：因?yàn)闊o需連接歧沪，因此是不可靠協(xié)議

（4）效率性

TCP：必須需要建立連接，所以效率稍微會(huì)低些

UDP：不需要建立連接莲组，速度快

3诊胞、TCP的三次握手與四次揮手

連接三次握手：

TCP是面向連接的，無論哪一方向另一方發(fā)送數(shù)據(jù)之前锹杈，都必須先在雙方之間建立一條連接撵孤。在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)竭望，連接是通過三次握手進(jìn)行初始化的邪码。三次握手的目的是同步連接雙方的序列號(hào)和確認(rèn)號(hào)并交換 TCP窗口大小信息。這就是面試中經(jīng)常會(huì)被問到的TCP三次握手咬清。只是了解TCP三次握手的概念闭专，對(duì)你獲得一份工作是沒有任何幫助的奴潘，你需要去了解TCP三次握手中的一些細(xì)節(jié)。先來看圖說話影钉。

多么清晰的一張圖画髓，當(dāng)然了，也不是我做的平委，是我從網(wǎng)上找來的奈虾。

（1）第一次握手：建立連接×猓客戶端發(fā)送連接請(qǐng)求報(bào)文段肉微，將SYN位置為1，Sequence Number為x昂勉；然后浪册，客戶端進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器的確認(rèn)岗照；

（2）第二次握手：服務(wù)器收到SYN報(bào)文段村象。服務(wù)器收到客戶端的SYN報(bào)文段，需要對(duì)這個(gè)SYN報(bào)文段進(jìn)行確認(rèn)攒至，設(shè)置Acknowledgment Number為x+1(Sequence Number+1)厚者；同時(shí)，自己自己還要發(fā)送SYN請(qǐng)求信息迫吐，將SYN位置為1库菲，Sequence Number為y；服務(wù)器端將上述所有信息放到一個(gè)報(bào)文段（即SYN+ACK報(bào)文段）中志膀，一并發(fā)送給客戶端熙宇，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；

（3）第三次握手：客戶端收到服務(wù)器的SYN+ACK報(bào)文段溉浙。然后將Acknowledgment Number設(shè)置為y+1烫止，向服務(wù)器發(fā)送ACK報(bào)文段，這個(gè)報(bào)文段發(fā)送完畢以后戳稽，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)馆蠕，完成TCP三次握手。

為了便于理解惊奇，我們忽略這些技術(shù)概念來理解三次握手：

A:“喂互躬，你聽得到嗎？”A->SYN_SEND

B:“我聽得到呀颂郎，你聽得到我嗎吼渡？”應(yīng)答與請(qǐng)求同時(shí)發(fā)出 B->SYN_RCVD | A->ESTABLISHED

A:“我能聽到你，今天balabala……”B->ESTABLISHED

完成了三次握手乓序，客戶端和服務(wù)器端就可以開始傳送數(shù)據(jù)诞吱。以上就是TCP三次握手的總體介紹舟奠。

斷開連接四次揮手：

當(dāng)客戶端和服務(wù)器通過三次握手建立了TCP連接以后，當(dāng)數(shù)據(jù)傳送完畢房维，肯定是要斷開TCP連接的啊。那對(duì)于TCP的斷開連接抬纸，這里就有了神秘的“四次分手”咙俩。

（1）第一次揮手：主機(jī)1（可以使客戶端，也可以是服務(wù)器端）湿故，設(shè)置Sequence Number和Acknowledgment Number阿趁，向主機(jī)2發(fā)送一個(gè)FIN報(bào)文段；此時(shí)坛猪，主機(jī)1進(jìn)入FIN_WAIT_1狀態(tài)脖阵；這表示主機(jī)1沒有數(shù)據(jù)要發(fā)送給主機(jī)2了；

（2）第二次揮手：主機(jī)2收到了主機(jī)1發(fā)送的FIN報(bào)文段墅茉，向主機(jī)1回一個(gè)ACK報(bào)文段命黔，Acknowledgment Number為Sequence Number加1；主機(jī)1進(jìn)入FIN_WAIT_2狀態(tài)就斤；主機(jī)2告訴主機(jī)1悍募，我“同意”你的關(guān)閉請(qǐng)求；

（3）第三次揮手：主機(jī)2向主機(jī)1發(fā)送FIN報(bào)文段洋机，請(qǐng)求關(guān)閉連接坠宴，同時(shí)主機(jī)2進(jìn)入LAST_ACK狀態(tài)；

（4）第四次揮手：主機(jī)1收到主機(jī)2發(fā)送的FIN報(bào)文段绷旗，向主機(jī)2發(fā)送ACK報(bào)文段喜鼓，然后主機(jī)1進(jìn)入TIME_WAIT狀態(tài)；主機(jī)2收到主機(jī)1的ACK報(bào)文段以后衔肢，就關(guān)閉連接庄岖；此時(shí)，主機(jī)1等待2MSL后依然沒有收到回復(fù)膀懈，則證明Server端已正常關(guān)閉顿锰，那好，主機(jī)1也可以關(guān)閉連接了启搂。

為了便于理解硼控，我們忽略這些技術(shù)概念來理解四次揮手：

A:“喂，我不說了胳赌±魏常”A->FIN_WAIT1

B:“我知道了。等下疑苫，上一句還沒說完熏版。Balabala…..”B->CLOSE_WAIT | A->FIN_WAIT2

B:”好了纷责，說完了，我也不說了撼短≡偕牛”B->LAST_ACK

A:”我知道了∏幔”A->TIME_WAIT | B->CLOSED

A等待2MSL,保證B收到了消息,否則重說一次”我知道了”,A->CLOSED

至此喂柒，TCP的四次分手就這么愉快的完成了。

為什么要三次握手禾嫉？

既然總結(jié)了TCP的三次握手灾杰，那為什么非要三次呢？怎么覺得兩次就可以完成了熙参。那TCP為什么非要進(jìn)行三次連接呢艳吠？在謝希仁的《計(jì)算機(jī)網(wǎng)絡(luò)》中是這樣說的：

“為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤孽椰≌衙洌”

在書中同時(shí)舉了一個(gè)例子，如下：

已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒有丟失弄屡，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長時(shí)間的滯留了题禀，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來這是一個(gè)早已失效的報(bào)文段膀捷。但server收到此失效的連接請(qǐng)求報(bào)文段后迈嘹，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。于是就向client發(fā)出確認(rèn)報(bào)文段全庸，同意建立連接秀仲。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)壶笼，新的連接就建立了神僵。由于現(xiàn)在client并沒有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)覆劈，也不會(huì)向server發(fā)送數(shù)據(jù)保礼。但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)责语。這樣炮障，server的很多資源就白白浪費(fèi)掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生坤候。例如剛才那種情況胁赢，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)白筹，就知道client并沒有要求建立連接智末×律悖”

這就很明白了，防止了服務(wù)器端的一直等待而浪費(fèi)資源系馆。

為什么要四次揮手送漠？

那四次分手又是為何呢？TCP協(xié)議是一種面向連接的由蘑、可靠的螺男、基于字節(jié)流的運(yùn)輸層通信協(xié)議。TCP是全雙工模式纵穿，這就意味著，當(dāng)主機(jī)1發(fā)出FIN報(bào)文段時(shí)奢人，只是表示主機(jī)1已經(jīng)沒有數(shù)據(jù)要發(fā)送了谓媒，主機(jī)1告訴主機(jī)2，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了何乎；但是句惯，這個(gè)時(shí)候主機(jī)1還是可以接受來自主機(jī)2的數(shù)據(jù)；當(dāng)主機(jī)2返回ACK報(bào)文段時(shí)支救，表示它已經(jīng)知道主機(jī)1沒有數(shù)據(jù)發(fā)送了抢野，但是主機(jī)2還是可以發(fā)送數(shù)據(jù)到主機(jī)1的；當(dāng)主機(jī)2也發(fā)送了FIN報(bào)文段時(shí)各墨，這個(gè)時(shí)候就表示主機(jī)2也沒有數(shù)據(jù)要發(fā)送了指孤，就會(huì)告訴主機(jī)1，我也沒有數(shù)據(jù)要發(fā)送了贬堵，之后彼此就會(huì)愉快的中斷這次TCP連接恃轩。如果要正確的理解四次分手的原理，就需要了解四次分手過程中的狀態(tài)變化：

FIN_WAIT_1: 這個(gè)狀態(tài)要好好解釋一下黎做，其實(shí)FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對(duì)方的FIN報(bào)文叉跛。而這兩種狀態(tài)的區(qū)別是：FIN_WAIT_1狀態(tài)實(shí)際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時(shí)，它想主動(dòng)關(guān)閉連接蒸殿，向?qū)Ψ桨l(fā)送了FIN報(bào)文筷厘，此時(shí)該SOCKET即進(jìn)入到FIN_WAIT_1狀態(tài)。而當(dāng)對(duì)方回應(yīng)ACK報(bào)文后宏所，則進(jìn)入到FIN_WAIT_2狀態(tài)酥艳，當(dāng)然在實(shí)際的正常情況下，無論對(duì)方何種情況下楣铁，都應(yīng)該馬上回應(yīng)ACK報(bào)文玖雁，所以FIN_WAIT_1狀態(tài)一般是比較難見到的，而FIN_WAIT_2狀態(tài)還有時(shí)常掣峭螅可以用netstat看到赫冬。（主動(dòng)方）

FIN_WAIT_2：上面已經(jīng)詳細(xì)解釋了這種狀態(tài)浓镜，實(shí)際上FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接劲厌，也即有一方要求close連接耍目，但另外還告訴對(duì)方嗦锐，我暫時(shí)還有點(diǎn)數(shù)據(jù)需要傳送給你(ACK信息)，稍后再關(guān)閉連接。（主動(dòng)方）

CLOSE_WAIT：這種狀態(tài)的含義其實(shí)是表示在等待關(guān)閉亚脆。怎么理解呢？當(dāng)對(duì)方close一個(gè)SOCKET后發(fā)送FIN報(bào)文給自己抵屿，你系統(tǒng)毫無疑問地會(huì)回應(yīng)一個(gè)ACK報(bào)文給對(duì)方摹恰，此時(shí)則進(jìn)入到CLOSE_WAIT狀態(tài)。接下來呢硼婿，實(shí)際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對(duì)方锌半，如果沒有的話，那么你也就可以 close這個(gè)SOCKET寇漫，發(fā)送FIN報(bào)文給對(duì)方刊殉，也即關(guān)閉連接。所以你在CLOSE_WAIT狀態(tài)下州胳，需要完成的事情是等待你去關(guān)閉連接记焊。（被動(dòng)方）

LAST_ACK: 這個(gè)狀態(tài)還是比較容易好理解的，它是被動(dòng)關(guān)閉一方在發(fā)送FIN報(bào)文后栓撞，最后等待對(duì)方的ACK報(bào)文遍膜。當(dāng)收到ACK報(bào)文后，也即可以進(jìn)入到CLOSED可用狀態(tài)了腐缤。（被動(dòng)方）

TIME_WAIT: 表示收到了對(duì)方的FIN報(bào)文捌归，并發(fā)送出了ACK報(bào)文，就等2MSL后即可回到CLOSED可用狀態(tài)了岭粤。如果FINWAIT1狀態(tài)下惜索，收到了對(duì)方同時(shí)帶FIN標(biāo)志和ACK標(biāo)志的報(bào)文時(shí)，可以直接進(jìn)入到TIME_WAIT狀態(tài)剃浇，而無須經(jīng)過FIN_WAIT_2狀態(tài)巾兆。（主動(dòng)方）

CLOSED: 表示連接中斷。

當(dāng)然虎囚，對(duì)于面向非連接的UDP則沒有上述復(fù)雜的過程角塑。

4、長連接與短連接

所謂長連接淘讥，指在一個(gè)TCP連接上可以連續(xù)發(fā)送多個(gè)數(shù)據(jù)包圃伶，在TCP連接保持期間，如果沒有數(shù)據(jù)包發(fā)送，需要雙方發(fā)檢測包以維持此連接窒朋，一般需要自己做在線維持搀罢。

短連接是指通信雙方有數(shù)據(jù)交互時(shí)，就建立一個(gè)TCP連接侥猩，數(shù)據(jù)發(fā)送完成后榔至，則斷開此TCP連接，一般銀行都使用短連接欺劳。

（1）TCP與長連接和短連接

TCP協(xié)議中有長連接和短連接之分唧取。短連接在數(shù)據(jù)包發(fā)送完成后就會(huì)自己斷開。而長連接在發(fā)包完畢后划提，會(huì)在一定的時(shí)間內(nèi)保持連接枫弟，并且可以繼續(xù)后續(xù)的讀寫操作，即我們通常所說的Keep alive（存活定時(shí)器）功能鹏往。它的功效和用戶自己實(shí)現(xiàn)的心跳機(jī)制是一樣的媒区。開啟Keep alive功能需要消耗額外的寬帶和流量，盡管這微不足道掸犬，但在按流量計(jì)費(fèi)的環(huán)境下增加了費(fèi)用，另一方面绪爸，Keep alive設(shè)置不合理時(shí)可能會(huì)因?yàn)槎虝旱木W(wǎng)絡(luò)波動(dòng)而斷開健康的TCP連接湾碎。

但keepalive并不是TCP規(guī)范的一部分。在Host Requirements RFC羅列有不使用它的三個(gè)理由：（1）在短暫的故障期間奠货，它們可能引起一個(gè)良好連接（good connection）被釋放（dropped）介褥，（2）它們消費(fèi)了不必要的寬帶，（3）在以數(shù)據(jù)包計(jì)費(fèi)的互聯(lián)網(wǎng)上它們（額外）花費(fèi)金錢递惋。然而柔滔，在許多的實(shí)現(xiàn)中提供了存活定時(shí)器。

UDP是面向非連接的萍虽，所以沒有長連接和短連接可言睛廊。

（2）長/短連接的應(yīng)用場景

長連接多用于操作頻繁，點(diǎn)對(duì)點(diǎn)的通訊杉编，而且連接數(shù)不能太多情況超全。每個(gè)TCP連接都需要三步握手，這需要時(shí)間邓馒，如果每個(gè)操作都是先連接嘶朱，再操作的話那么處理速度會(huì)降低很多，所以每個(gè)操作完后都不斷開光酣，再次處理時(shí)直接發(fā)送數(shù)據(jù)包就OK了疏遏，不用建立TCP連接。例如：數(shù)據(jù)庫的連接用長連接，如果用短連接頻繁的通信會(huì)造成socket錯(cuò)誤财异，而且頻繁的socket 創(chuàng)建也是對(duì)資源的浪費(fèi)倘零。

而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接，因?yàn)殚L連接對(duì)于服務(wù)端來說會(huì)耗費(fèi)一定的資源宝当，而像WEB網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會(huì)更省一些資源视事，如果用長連接，而且同時(shí)有成千上萬的用戶庆揩，如果每個(gè)用戶都占用一個(gè)連接的話俐东，那后果可想而知。所以并發(fā)量大订晌，但每個(gè)用戶無需頻繁操作情況下需用短連好虏辫。

（3）基于TCP協(xié)議的HTTP協(xié)議到底是長連接還是短連接（重點(diǎn)）？

在HTTP/1.0中锈拨，默認(rèn)使用的是短連接砌庄。也就是說，瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作奕枢，就建立一次連接娄昆，但任務(wù)結(jié)束就中斷連接。如果客戶端瀏覽器訪問的某個(gè)HTML或其他類型的Web頁中包含有其他的Web資源缝彬，如JavaScript文件萌焰、圖像文件、CSS文件等谷浅；當(dāng)瀏覽器每遇到這樣一個(gè)Web資源扒俯，就會(huì)建立一個(gè)HTTP會(huì)話。

但從HTTP/1.1起一疯，默認(rèn)使用長連接撼玄，用以保持連接特性。使用長連接的HTTP協(xié)議墩邀，會(huì)在響應(yīng)頭有加入這行代碼：

Connection:keep-alive

在使用長連接的情況下掌猛，當(dāng)一個(gè)網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的 TCP連接不會(huì)關(guān)閉眉睹，如果客戶端再次訪問這個(gè)服務(wù)器上的網(wǎng)頁留潦，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會(huì)永久保持連接辣往，它有一個(gè)保持時(shí)間兔院，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長連接要客戶端和服務(wù)端都支持長連接站削。

注意坊萝，TCP的keep alive和HTTP的Keep-alive不是同一個(gè)東西，TCP的keep alive是檢查當(dāng)前TCP連接是否活著；HTTP的Keep-alive是要讓一個(gè)TCP連接活久點(diǎn)十偶。它們是不同層次的概念菩鲜。

HTTP協(xié)議的長連接和短連接，實(shí)質(zhì)上是TCP協(xié)議的長連接和短連接惦积。

關(guān)于TCP你也可以看這里：就是要你懂TCP