網(wǎng)絡(luò)七層：物理層昭灵，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層伐谈，傳輸層烂完，會(huì)話層，表示層诵棵，應(yīng)用層抠蚣。

一.TCP/IP

tcp/ip協(xié)議：是一種傳輸層協(xié)議。主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸非春。

二.HTTP

• http協(xié)議：超文本協(xié)議柱徙，是一種應(yīng)用層協(xié)議，主要是解決如何包裝數(shù)據(jù)奇昙。它常基于tcp/ip協(xié)議進(jìn)行連接敌完。
• https協(xié)議：安全超文本協(xié)議储耐，是在http協(xié)議（信息是明文傳輸）的基礎(chǔ)上，使用了SSL進(jìn)行加密滨溉，即https=http+SSL什湘。
• 短連接：連接->數(shù)據(jù)傳輸->關(guān)閉連接任務(wù)結(jié)束就中斷連接长赞。

三.Socket

• Socket是對(duì)tcp/ip協(xié)議的封裝，是一個(gè)調(diào)用的接口api闽撤。通過該Socket才能使用tcp/ip協(xié)議得哆。
• 長(zhǎng)連接：連接->傳輸數(shù)據(jù)->保持連接->傳輸數(shù)據(jù)...->關(guān)閉連接，安全性較差哟旗。

四.Socket連接與斷開

Socket連接是由底層封裝的tcp協(xié)議發(fā)起的贩据，tcp協(xié)議需要經(jīng)過“三次握手”來完成：

• 第一次握手：客戶端發(fā)送一個(gè)syn包給服務(wù)器，然后進(jìn)入SYN_SEND狀態(tài)闸餐，等待服務(wù)器確認(rèn)饱亮。

解釋：客戶端發(fā)送的這個(gè)syn包給服務(wù)器，是為了告訴服務(wù)器舍沙，客戶端的序列號(hào)為X近上。

• 第二次握手：服務(wù)器收到客戶端的syn包，先確認(rèn)客戶端的syn包拂铡，發(fā)送一個(gè)syn+ack包給客戶端壹无，然后進(jìn)入SYN_RECV狀態(tài)。

解釋：服務(wù)器確認(rèn)客戶端的syn包之后感帅，服務(wù)器就知道客戶端的序列號(hào)是X格遭。服務(wù)器發(fā)送給客戶端的syn+ack包，當(dāng)中包含一個(gè)ack包和一個(gè)syn包留瞳。其中的ack包是服務(wù)器為了告訴客戶端拒迅，服務(wù)器已經(jīng)收到了客戶端的syn包，并且知道客戶端的序列號(hào)是X她倘；其中的syn包是服務(wù)器為了告訴客戶端璧微，服務(wù)器的序列號(hào)為Y。

• 第三次握手：客戶端收到服務(wù)器的syn+ack包硬梁，再向服務(wù)器發(fā)送一個(gè)ack包前硫。發(fā)送完畢，客戶端和服務(wù)器都進(jìn)入ESTABLISHED狀態(tài)荧止，連接建立屹电。

解釋：客戶端收到服務(wù)器的syn+ack包，通過其中的syn包知道服務(wù)器的序列號(hào)為Y跃巡。然后再向服務(wù)器發(fā)送的ack包是客戶端為了告訴服務(wù)器危号，客戶端已經(jīng)知道收到了服務(wù)器的syn+ack包，并且知道服務(wù)器的序列號(hào)為Y素邪。

注：三次握手過程中發(fā)送的這些包不包含數(shù)據(jù)外莲，三次握手完成之后，連接建立，客戶端與服務(wù)器之間才開始傳送數(shù)據(jù)偷线。

在理想狀態(tài)下磨确，tcp連接一旦建立，在通信雙方中的任何一方主動(dòng)關(guān)閉連接之前声邦，tcp連接都將被一直保持下去乏奥。斷開連接時(shí)服務(wù)器和客戶端均可以主動(dòng)發(fā)起斷開tcp連接的請(qǐng)求，斷開過程需要經(jīng)過“四次揮手”來完成（下面由客戶端發(fā)起關(guān)閉tcp連接）：

• 第一次揮手：客戶端會(huì)發(fā)送一個(gè)FIN報(bào)文給服務(wù)器亥曹，并且停止發(fā)送數(shù)據(jù)邓了，然后進(jìn)入FIN-WAIT-1狀態(tài)（終止等待1狀態(tài),等待服務(wù)器的響應(yīng)）。

解釋：FIN報(bào)文即連接釋放報(bào)文歇式，客戶端發(fā)送FIN報(bào)文給服務(wù)器驶悟，是為了告訴服務(wù)器，客戶端的序列號(hào)是X材失，客戶端請(qǐng)求關(guān)閉連接痕鳍。

• 第二次揮手：服務(wù)器接收到FIN報(bào)文之后, 先確認(rèn)客戶端的FIN報(bào)文, 再發(fā)送一條ack包給客戶端，服務(wù)器進(jìn)入CLOSE_WAIT狀態(tài)（關(guān)閉等待）龙巨。

解釋：服務(wù)器確認(rèn)客戶端的FIN報(bào)文之后笼呆，就知道了客戶端的序列號(hào)是X，請(qǐng)求關(guān)閉連接旨别。發(fā)送一條ack包給客戶端诗赌，是服務(wù)器為了告訴客戶端，服務(wù)器已經(jīng)收到了客戶端的FIN報(bào)文秸弛，并且知道客戶端的序列號(hào)是X铭若。當(dāng)客戶端收到服務(wù)器的ack包之后，客戶端就進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)递览。這個(gè)時(shí)候叼屠，整個(gè)tcp連接處于一個(gè)半關(guān)閉狀態(tài),即客戶端已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是服務(wù)器若發(fā)送數(shù)據(jù)绞铃，客戶端依然要接受镜雨。

• 第三次揮手：服務(wù)器發(fā)送一條FIN報(bào)文給客戶端，服務(wù)器進(jìn)入LAST-ACK（最后確認(rèn)）狀態(tài)儿捧。

解釋：服務(wù)器發(fā)送一條FIN報(bào)文給客戶端荚坞，是為了告訴客戶端，服務(wù)器的序列號(hào)為Y菲盾，服務(wù)器已經(jīng)沒有數(shù)據(jù)要發(fā)送了颓影，現(xiàn)在可以關(guān)閉tcp連接了。

• 第四次揮手：客戶端收到服務(wù)器的FIN報(bào)文亿汞，先確認(rèn)服務(wù)器的FIN報(bào)文瞭空，然后發(fā)送一條ack包給服務(wù)器，客戶端就進(jìn)入了TIME-WAIT（時(shí)間等待）狀態(tài)疗我。

解釋：客戶端確認(rèn)服務(wù)器的FIN報(bào)文之后咆畏，就知道了服務(wù)器的序列號(hào)是Y，并且已經(jīng)沒有數(shù)據(jù)要傳送了吴裤。然后客戶端再發(fā)送一條ack包給服務(wù)器旧找，是為了告訴服務(wù)器，客戶端知道了麦牺∨ブ耄客戶端進(jìn)入了TIME-WAIT（時(shí)間等待）狀態(tài)。
注意剖膳，這個(gè)時(shí)候客戶端進(jìn)入時(shí)間等待狀態(tài)魏颓，tcp連接還沒有關(guān)閉，必須等到服務(wù)端收到ack包吱晒，進(jìn)入CLOSED狀態(tài)甸饱，客戶端也從時(shí)間等待狀態(tài)進(jìn)入CLOSED狀態(tài)之后，tcp連接才關(guān)閉仑濒。

五.HTTP連接

http連接是客戶端發(fā)送的每個(gè)請(qǐng)求都需要服務(wù)器那邊響應(yīng)回送叹话，當(dāng)請(qǐng)求結(jié)束的時(shí)候，就自動(dòng)關(guān)閉http連接墩瞳，因此被稱為短連接驼壶。因此要保持客戶端程序的在線狀態(tài)，就需要不斷的向服務(wù)器發(fā)送連接請(qǐng)求喉酌。

• 即使不需要獲得任何數(shù)據(jù)热凹，客戶端也保持每隔一段固定的時(shí)間向服務(wù)器發(fā)送一次保持連接的請(qǐng)求。
• 服務(wù)器如果收到客戶端的連接請(qǐng)求進(jìn)行回復(fù)泪电，服務(wù)器就知道客戶端在線狀態(tài)般妙。如果長(zhǎng)時(shí)間無法收到客戶的的連接請(qǐng)求，服務(wù)器就認(rèn)為客戶端下線狀態(tài)歪架。
• 如果客戶端發(fā)送了連接請(qǐng)求但是收不到服務(wù)器的回復(fù)股冗，客戶端則認(rèn)為網(wǎng)絡(luò)斷開。

六.UDP與TCP對(duì)比

UDP與TCP一樣和蚪，也是一種傳輸層的協(xié)議止状。不過udp協(xié)議不需要像tcp協(xié)議那樣建立連接（即tcp協(xié)議的三次握手），所以：

• tcp：面向連接（傳輸數(shù)據(jù)前需要先建立tcp連接 三次握手）攒霹，傳輸可靠怯疤，一般不會(huì)出現(xiàn)數(shù)據(jù)丟包現(xiàn)象（建立連接可以保證數(shù)據(jù)的安全）。但是傳輸速度比較慢催束，會(huì)出現(xiàn)延遲現(xiàn)象（建立連接需要時(shí)間和系統(tǒng)資源的消耗）集峦。適合用于傳輸數(shù)據(jù)量級(jí)大的數(shù)據(jù)，由于客戶端和服務(wù)器的連接要長(zhǎng)時(shí)間保持著，對(duì)服務(wù)器的消耗相對(duì)來說比較大塔淤。

例如：公司內(nèi)部的局域網(wǎng)摘昌。

• udp：面向非連接，傳輸不可靠高蜂，經(jīng)常會(huì)出現(xiàn)數(shù)據(jù)丟包現(xiàn)象聪黎。但是傳輸速度比較快，不會(huì)出現(xiàn)延遲現(xiàn)象备恤。適合用于傳輸數(shù)據(jù)量級(jí)小的數(shù)據(jù)（數(shù)據(jù)量級(jí)越大越容易出現(xiàn)數(shù)據(jù)丟包現(xiàn)象）稿饰，對(duì)服務(wù)器的消耗相對(duì)來說比較小。

例如：大規(guī)模即時(shí)通訊軟件（微信露泊，QQ）喉镰。

• 使用tcp協(xié)議與客戶端進(jìn)行短命連接，這樣既能確保數(shù)據(jù)的安全性惭笑，又能減少對(duì)服務(wù)器的消耗侣姆。這種情況適用于客戶端與服務(wù)器數(shù)據(jù)交互不是很頻繁的業(yè)務(wù)。

例如：客戶端向服務(wù)器請(qǐng)求好友列表的數(shù)據(jù)脖咐，先建立tcp連接铺敌，然后傳輸數(shù)據(jù)，數(shù)據(jù)傳輸完成屁擅，關(guān)閉連接偿凭。等到下次需要請(qǐng)求還有列表數(shù)據(jù)時(shí)再重新建立連接。

七.選擇哪種協(xié)議的問題

• 如果是只由客戶端發(fā)起的間隔性的連接請(qǐng)求派歌，可以發(fā)生延遲現(xiàn)象弯囊，那么使用http/https。
• 如果是由客戶端或服務(wù)端發(fā)起的連接請(qǐng)求胶果，可以發(fā)生延遲現(xiàn)象匾嘱，那么使用tcp。
• 如果是由客戶端或服務(wù)端發(fā)起的連接請(qǐng)求早抠，不可以發(fā)生延遲現(xiàn)象霎烙，那么使用udp。