TCP、UDP的區(qū)別
TCP（Transmission Control Protocol痊乾，傳輸控制協(xié)議）是面向連接的協(xié)議嗦明，也就是說，在收發(fā)數(shù)據(jù)前凯楔，必須和對方建立可靠的連接窜骄。 一個TCP連接必須要經(jīng)過三次“對話”才能建立起來，其中的過程非常復(fù)雜摆屯， 只簡單的描述下這三次對話的簡單過程：
1）主機A向主機B發(fā)出連接請求數(shù)據(jù)包：“我想給你發(fā)數(shù)據(jù)邻遏，可以嗎？”虐骑，這是第一次對話准验；
2）主機B向主機A發(fā)送同意連接和要求同步 （同步就是兩臺主機一個在發(fā)送，一個在接收富弦，協(xié)調(diào)工作）的數(shù)據(jù)包 ：“可以沟娱，你什么時候發(fā)？”腕柜，這是第二次對話济似；
3）主機A再發(fā)出一個數(shù)據(jù)包確認主機B的要求同步：“我現(xiàn)在就發(fā)，你接著吧盏缤！”砰蠢， 這是第三次對話。
三次“對話”的目的是使數(shù)據(jù)包的發(fā)送和接收同步唉铜， 經(jīng)過三次“對話”之后台舱，主機A才向主機B正式發(fā)送數(shù)據(jù)。
TCP三次握手過程
第一次握手：主機A通過向主機B 發(fā)送一個含有同步序列號的標志位的數(shù)據(jù)段給主機B，向主機B 請求建立連接竞惋，通過這個數(shù)據(jù)段柜去， 主機A告訴主機B 兩件事：我想要和你通信；你可以用哪個序列號作為起始數(shù)據(jù)段來回應(yīng)我拆宛。
第二次握手：主機B 收到主機A的請求后嗓奢，用一個帶有確認應(yīng)答（ACK）和同步序列號（SYN）標志位的數(shù)據(jù)段響應(yīng)主機A，也告訴主機A兩件事：我已經(jīng)收到你的請求了浑厚，你可以傳輸數(shù)據(jù)了股耽；你要用那個序列號作為起始數(shù)據(jù)段來回應(yīng)我
第三次握手：主機A收到這個數(shù)據(jù)段后，再發(fā)送一個確認應(yīng)答钳幅，確認已收到主機B 的數(shù)據(jù)段："我已收到回復(fù)物蝙，我現(xiàn)在要開始傳輸實際數(shù)據(jù)了，這樣3次握手就完成了敢艰，主機A和主機B 就可以傳輸數(shù)據(jù)了诬乞。
TCP建立連接要進行3次握手，而斷開連接要進行4次
第一次： 當主機A完成數(shù)據(jù)傳輸后,將控制位FIN置1钠导，提出停止TCP連接的請求 丽惭；
第二次： 主機B收到FIN后對其作出響應(yīng)，確認這一方向上的TCP連接將關(guān)閉,將ACK置1辈双；
第三次： 由B 端再提出反方向的關(guān)閉請求,將FIN置1 ；
第四次： 主機A對主機B的請求進行確認柜砾，將ACK置1湃望，雙方向的關(guān)閉結(jié)束.。
由TCP的三次握手和四次斷開可以看出痰驱，TCP使用面向連接的通信方式证芭， 大大提高了數(shù)據(jù)通信的可靠性，使發(fā)送數(shù)據(jù)端和接收端在數(shù)據(jù)正式傳輸前就有了交互担映， 為數(shù)據(jù)正式傳輸打下了可靠的基礎(chǔ)废士。
1.基于連接與無連接
2.TCP要求系統(tǒng)資源較多，UDP較少蝇完；
3.UDP程序結(jié)構(gòu)較簡單
4.流模式（TCP）與數(shù)據(jù)報模式(UDP);
5.TCP保證數(shù)據(jù)正確性官硝，UDP可能丟包
6.TCP保證數(shù)據(jù)順序，UDP不保證
為什么要三次握手短蜕？
為了防止已失效的連接請求報文段突然又傳送到了服務(wù)端氢架，因而產(chǎn)生錯誤。
為什么要四次揮手朋魔？
TCP是全雙工模式岖研，這就意味著，當主機1發(fā)出FIN報文段時警检，只是表示主機1已經(jīng)沒有數(shù)據(jù)要發(fā)送了孙援，主機1告訴主機2害淤，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了；但是拓售，這個時候主機1還是可以接受來自主機2的數(shù)據(jù)窥摄；當主機2返回ACK報文段時，表示它已經(jīng)知道主機1沒有數(shù)據(jù)發(fā)送了邻辉，但是主機2還是可以發(fā)送數(shù)據(jù)到主機1的溪王；當主機2也發(fā)送了FIN報文段時，這個時候就表示主機2也沒有數(shù)據(jù)要發(fā)送了值骇，就會告訴主機1莹菱，我也沒有數(shù)據(jù)要發(fā)送，之后就會中斷這次TCP連接吱瘩。
為什么TIME_WAIT狀態(tài)需要保持2MSL這么長的時間道伟？
如果TIME_WAIT狀態(tài)保持時間不足夠長，第一個連接就正常終止了使碾。第二個擁有相同五元組的連接出現(xiàn)蜜徽，而第一個連接的重復(fù)報文到達，干擾了第二個連接票摇。TCP事先必須防止某個連接的重復(fù)報文在連接終止后出現(xiàn)拘鞋，所以讓TIME_WAIT狀態(tài)保持時間足夠長(2MSL)，連接相應(yīng)方向的上的TCP報文要么完全響應(yīng)完畢矢门，要么被丟棄盆色。建立第二個連接的時候，不會混淆祟剔。
1隔躲、 為什么建立連接協(xié)議是三次握手，而關(guān)閉連接卻是四次握手呢物延？
這是因為服務(wù)端的LISTEN狀態(tài)下的SOCKET當收到SYN報文的建連請求后宣旱，它可以把ACK和SYN（ACK起應(yīng)答作用，而SYN起同步作用）放在一個報文里來發(fā)送叛薯。但關(guān)閉連接時浑吟，當收到對方的FIN報文通知時，它僅僅表示對方?jīng)]有數(shù)據(jù)發(fā)送給你了耗溜；但未必你所有的數(shù)據(jù)都全部發(fā)送給對方了买置，所以你可能未必會馬上會關(guān)閉SOCKET,也即你可能還需要發(fā)送一些數(shù)據(jù)給對方之后，再發(fā)送FIN報文給對方來表示你同意現(xiàn)在可以關(guān)閉連接了强霎，所以它這里的ACK報文和FIN報文多數(shù)情況下都是分開發(fā)送的忿项。
2. 為什么不能用兩次握手進行連接？
我們知道，3次握手完成兩個重要的功能轩触，既要雙方做好發(fā)送數(shù)據(jù)的準備工作(雙方都知道彼此已準備好)寞酿，也要允許雙方就初始序列號進行協(xié)商，這個序列號在握手過程中被發(fā)送和確認脱柱。
現(xiàn)在把三次握手改成僅需要兩次握手伐弹，死鎖是可能發(fā)生的。作為例子榨为，考慮計算機S和C之間的通信惨好，假定C給S發(fā)送一個連接請求分組，S收到了這個分組随闺，并發(fā)送了確認應(yīng)答分組日川。按照兩次握手的協(xié)定，S認為連接已經(jīng)成功地建立了矩乐，可以開始發(fā)送數(shù)據(jù)分組龄句。可是散罕，C在 S的應(yīng)答分組在傳輸中被丟失的情況下分歇，將不知道S是否已準備好，不知道S建立什么樣的序列號欧漱，C甚至懷疑S是否收到自己的連接請求分組职抡。在這種情況下，C認為連接還未建立成功误甚，將忽略S發(fā)來的任何數(shù)據(jù)分組繁调，只等待連接確認應(yīng)答分組。而S在發(fā)出的數(shù)據(jù)分組超時后靶草，重復(fù)發(fā)送同樣的數(shù)據(jù)分組。這樣就形成了死鎖岳遥。
3. 為什么TIME_WAIT狀態(tài)還需要等2MSL后才能返回到CLOSED狀態(tài)奕翔？
什么是2MSL？MSL即Maximum Segment Lifetime浩蓉，也就是報文最大生存時間派继，引用《TCP/IP詳解》中的話：“它(MSL)是任何報文段被丟棄前在網(wǎng)絡(luò)內(nèi)的最長時間∧硌蓿”那么驾窟，2MSL也就是這個時間的2倍，當TCP連接完成四個報文段的交換時认轨，主動關(guān)閉的一方將繼續(xù)等待一定時間(2-4分鐘)绅络，即使兩端的應(yīng)用程序結(jié)束。例如在客戶端關(guān)閉后，使用netstat查看的結(jié)果:
C:>netstat -na | find "172.29.21.25"
TCP 172.29.132.60:2795 172.29.21.25:23 TIME_WAIT
為什么需要這個2MSL呢恩急？
第一杉畜，雖然雙方都同意關(guān)閉連接了，而且握手的4個報文也都協(xié)調(diào)和發(fā)送完畢衷恭，按理可以直接回到CLOSED狀態(tài)（就好比從SYN_SEND狀態(tài)到ESTABLISH狀態(tài)那樣）此叠；但是因為我們必須要假想網(wǎng)絡(luò)是不可靠的，你無法保證你最后發(fā)送的ACK報文會一定被對方收到随珠，因此對方處于LAST_ACK狀態(tài)下的SOCKET可能會因為超時未收到ACK報文灭袁，而重發(fā)FIN報文，所以這個TIME_WAIT狀態(tài)的作用就是用來重發(fā)可能丟失的ACK報文窗看。
第二茸歧，報文可能會被混淆，意思是說烤芦，其他時候的連接可能會被當作本次的連接举娩。直接引用《The TCP/IP Guide》的說法：The second is to provide a “buffering period” between the end of this connection and any subsequent ones. If not for this period, it is possible that packets from different connections could be mixed, creating confusion.
當某個連接的一端處于TIME_WAIT狀態(tài)時，該連接將不能再被使用构罗。事實上铜涉，對于我們比較有現(xiàn)實意義的是，這個端口將不能再被使用遂唧。某個端口處于TIME_WAIT狀態(tài)(其實應(yīng)該是這個連接)時芙代，這意味著這個TCP連接并沒有斷開(完全斷開)，那么盖彭，如果你bind這個端口纹烹，就會失敗。對于服務(wù)器而言召边，如果服務(wù)器突然crash掉了铺呵，那么它將無法在2MSL內(nèi)重新啟動，因為bind會失敗隧熙。解決這個問題的一個方法就是設(shè)置socket的SO_REUSEADDR選項片挂。這個選項意味著你可以重用一個地址。
當建立一個TCP連接時贞盯，服務(wù)器端會繼續(xù)用原有端口監(jiān)聽音念，同時用這個端口與客戶端通信。而客戶端默認情況下會使用一個隨機端口與服務(wù)器端的監(jiān)聽端口通信躏敢。有時候闷愤，為了服務(wù)器端的安全性，我們需要對客戶端進行驗證件余，即限定某個IP某個特定端口的客戶端讥脐≡饩樱客戶端可以使用bind來使用特定的端口。對于服務(wù)器端攘烛，當設(shè)置了SO_REUSEADDR選項時魏滚，它可以在2MSL內(nèi)啟動并listen成功。但是對于客戶端坟漱，當使用bind并設(shè)置SO_REUSEADDR時鼠次，如果在2MSL內(nèi)啟動，雖然bind會成功芋齿，但是在windows平臺上connect會失敗腥寇。而在Linux上則不存在這個問題。(我的實驗平臺：winxp, ubuntu7.10)
要解決windows平臺的這個問題觅捆，可以設(shè)置SO_LINGER選項赦役。SO_LINGER選項決定調(diào)用close時TCP的行為。SO_LINGER涉及到linger結(jié)構(gòu)體栅炒，如果設(shè)置結(jié)構(gòu)體中l(wèi)_onoff為非0掂摔，l_linger為0，那么調(diào)用close時TCP連接會立刻斷開赢赊，TCP不會將發(fā)送緩沖中未發(fā)送的數(shù)據(jù)發(fā)送乙漓，而是立即發(fā)送一個RST報文給對方，這個時候TCP連接(關(guān)閉時)就不會進入TIME_WAIT狀態(tài)释移。如你所見叭披，這樣做雖然解決了問題，但是并不安全玩讳。通過以上方式設(shè)置SO_LINGER狀態(tài)涩蜘，等同于設(shè)置SO_DONTLINGER狀態(tài)。
當TCP連接發(fā)生一些物理上的意外情況時熏纯，例如網(wǎng)線斷開同诫，linux上的TCP實現(xiàn)會依然認為該連接有效，而windows則會在一定時間后返回錯誤信息樟澜。這似乎可以通過設(shè)置SO_KEEPALIVE選項來解決误窖，不過不知道這個選項是否對于所有平臺都有效。
TCP粘包是指發(fā)送方發(fā)送的若干包數(shù)據(jù)到接收方接收時粘成一包往扔，從接收緩沖區(qū)看，后一包數(shù)據(jù)的頭緊接著前一包數(shù)據(jù)的尾熊户。
比如發(fā)送端發(fā)送了一個由2個100字節(jié)組成的200字節(jié)的數(shù)據(jù)包到接受端的緩沖區(qū)萍膛，接受端從緩沖去一次取80字節(jié)的數(shù)據(jù)，那么第一次取的就是一個不完整的數(shù)據(jù)包嚷堡，第二次取就會帶上第一個數(shù)據(jù)包的尾部和下一個數(shù)據(jù)包的頭
一個完成的消息可能會被TCP拆分成多個包進行發(fā)送蝗罗，也有可能把多個小的包封裝成一個大的數(shù)據(jù)包發(fā)送艇棕，這個就是TCP的拆包和封包問題
傳輸層無法保證數(shù)據(jù)的可靠傳輸，只能通過應(yīng)用層來實現(xiàn)了串塑。實現(xiàn)的方式可以參照tcp可靠性傳輸?shù)姆绞秸恿穑皇菍崿F(xiàn)不在傳輸層，實現(xiàn)轉(zhuǎn)移到了應(yīng)用層桩匪。
1打瘪、添加seq/ack機制，確保數(shù)據(jù)發(fā)送到對端
2傻昙、添加發(fā)送和接收緩沖區(qū)闺骚，主要是用戶超時重傳。
3妆档、添加超時重傳機制
TIME_WAIT狀態(tài)處在哪一方以及為什么需要它
TCP流量控制僻爽、擁塞控制
https://blog.csdn.net/liuchenxia8/article/details/80428157
一：流量控制
什么是流量控制？流量控制的目的贾惦？
如果發(fā)送者發(fā)送數(shù)據(jù)過快胸梆，接收者來不及接收，那么就會有分組丟失须板。為了避免分組丟失碰镜，控制發(fā)送者的發(fā)送速度，使得接收者來得及接收逼纸，這就是流量控制洋措。流量控制根本目的是防止分組丟失，它是構(gòu)成TCP可靠性的一方面杰刽。
如何實現(xiàn)流量控制菠发？
由滑動窗口協(xié)議（連續(xù)ARQ協(xié)議）實現(xiàn)『厣滑動窗口協(xié)議既保證了分組無差錯滓鸠、有序接收，也實現(xiàn)了流量控制第喳。主要的方式就是接收方返回的 ACK 中會包含自己的接收窗口的大小糜俗，并且利用大小來控制發(fā)送方的數(shù)據(jù)發(fā)送。
流量控制引發(fā)的死鎖曲饱？怎么避免死鎖的發(fā)生悠抹？
當發(fā)送者收到了一個窗口為0的應(yīng)答，發(fā)送者便停止發(fā)送扩淀，等待接收者的下一個應(yīng)答楔敌。但是如果這個窗口不為0的應(yīng)答在傳輸過程丟失，發(fā)送者一直等待下去驻谆，而接收者以為發(fā)送者已經(jīng)收到該應(yīng)答卵凑，等待接收新數(shù)據(jù)庆聘，這樣雙方就相互等待，從而產(chǎn)生死鎖勺卢。
為了避免流量控制引發(fā)的死鎖伙判，TCP使用了持續(xù)計時器。每當發(fā)送者收到一個零窗口的應(yīng)答后就啟動該計時器黑忱。時間一到便主動發(fā)送報文詢問接收者的窗口大小宴抚。若接收者仍然返回零窗口，則重置該計時器繼續(xù)等待杨何；若窗口不為0酱塔，則表示應(yīng)答報文丟失了，此時重置發(fā)送窗口后開始發(fā)送危虱，這樣就避免了死鎖的產(chǎn)生羊娃。
二：擁塞控制和流量控制的區(qū)別
擁塞控制：擁塞控制是作用于網(wǎng)絡(luò)的，它是防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中埃跷，避免出現(xiàn)網(wǎng)絡(luò)負載過大的情況蕊玷；常用的方法就是：（ 1 ）慢開始、擁塞避免（ 2 ）快重傳弥雹、快恢復(fù)垃帅。
流量控制：流量控制是作用于接收者的，它是控制發(fā)送者的發(fā)送速度從而使接收者來得及接收剪勿，防止分組丟失的贸诚。
三：擁塞控制的算法
慢開始，擁塞避免 快重傳厕吉，快恢復(fù)算法酱固。
TCP協(xié)議------可靠性保證機制
DNS如何解析
1.遞歸查詢
2.迭代查詢
控制器、運算器头朱、存儲器运悲、輸入設(shè)備、輸出設(shè)備五部分組成馮·諾伊曼提出的計算機體系結(jié)構(gòu)
