一、OSI七層模型

參考鏈接：http://www.itdecent.cn/p/9b9438dff7a2
參考模型是國際標(biāo)準(zhǔn)化組織(ISO)制定的一個用于計(jì)算機(jī)或通信系統(tǒng)間互聯(lián)的標(biāo)準(zhǔn)體系，一般稱為OSI參考模型或七層模型。

1）七層模型從上到下依次是

應(yīng)用層：協(xié)議有HTTP 、FTP、 TFTP、 SMTP、 SNMP、 DNS 、TELNET 、HTTPS、 POP3、 DHCP
表示層：數(shù)據(jù)的表示、安全、壓縮。格式有，JPEG、ASCll、DECOIC、加密格式等
會話層：建立、管理、終止會話。對應(yīng)主機(jī)進(jìn)程，指本地主機(jī)與遠(yuǎn)程主機(jī)正在進(jìn)行的會話
傳輸層：定義傳輸數(shù)據(jù)的協(xié)議端口號，以及流控和差錯校驗(yàn)。協(xié)議有：TCP 、UDP，數(shù)據(jù)包一旦離開網(wǎng)卡即進(jìn)入網(wǎng)絡(luò)傳輸層
網(wǎng)絡(luò)層：進(jìn)行邏輯地址尋址，實(shí)現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇。協(xié)議有：ICMP 、IGMP、 IP（IPV4 IPV6）、 ARP、 RARP
數(shù)據(jù)鏈路層：建立邏輯連接、進(jìn)行硬件地址尋址、差錯校驗(yàn)等功能。將比特組合成字節(jié)進(jìn)而組合成幀，用MAC地址訪問介質(zhì)，錯誤發(fā)現(xiàn)但不能糾正。
物理層：建立、維護(hù)、斷開物理連接。

2）七層模型圖示

七層模型1

七層模型2

3）七層模型傳輸數(shù)據(jù)過程

七層模型傳輸數(shù)據(jù)過程

二、TCP協(xié)議

TCP 全稱傳輸控制協(xié)議，必須對數(shù)據(jù)的傳輸進(jìn)行控制。

1. TCP 報(bào)文格式：

報(bào)文格式

• URG: 它為了標(biāo)志緊急指針是否有效。
• ACK：標(biāo)識確認(rèn)號是否有效。
• PSH: 提示接收端應(yīng)用程序立即將接收緩沖區(qū)的數(shù)據(jù)拿走。
• RST：它是為了處理異常連接的， 告訴連接不一致的一方，我們的連接還沒有建立好， 要求對方重新建立連接。我們把攜帶 RST 標(biāo)識的稱為復(fù)位報(bào)文段。
• SYN: 請求建立連接; 我們把攜帶 SYN 標(biāo)識的稱為同步報(bào)文段。
• FIN: 通知對方, 本端要關(guān)閉連接了, 我們稱攜帶 FIN 標(biāo)識的為結(jié)束報(bào)文段。

6）16 位的緊急指針：按序到達(dá)是TCP協(xié)議保證可靠性的一種機(jī)制，但是也存在一些報(bào)文想優(yōu)先被處理，這時就可以設(shè)置緊急指針，指向該報(bào)文即可，同時將緊急指針有效位置位1。
緊急
7）16 位窗口大小：如果發(fā)送方發(fā)送大量數(shù)據(jù)，接收方接收不過來，會導(dǎo)致大量數(shù)據(jù)丟失。然后接收方可以發(fā)送給發(fā)送發(fā)消息讓發(fā)送方發(fā)慢一點(diǎn)，這是流量控制。接收方將自己接收緩沖器剩余空間的大小告訴發(fā)送方叫做16位窗口大小。發(fā)送發(fā)可以根據(jù)窗口大小來適配發(fā)送的速度和大小，窗口大小最大是 2 的 16 次方，及 64KB，但也可以根據(jù)選項(xiàng)中的某些位置擴(kuò)展，最大擴(kuò)展 1G。
8）16 位校驗(yàn)和：發(fā)送端填充，CRC校驗(yàn)。如果接收端校驗(yàn)不通過， 則認(rèn)為數(shù)據(jù)有問題 (此處的檢驗(yàn)和不光包含TCP首部也包含TCP數(shù)據(jù)部分)。

2. TCP可靠傳輸

TCP保證可靠傳輸?shù)姆绞剑?/p>

• 數(shù)據(jù)校驗(yàn)：TCP報(bào)文頭有校驗(yàn)和，用于校驗(yàn)報(bào)文是否損壞
• 確認(rèn)應(yīng)答：接收方收到報(bào)文就會給發(fā)送方發(fā)送確認(rèn)ACK報(bào)文
• 超時重傳：發(fā)送方發(fā)送一段時間后沒有收到確認(rèn)就會重傳
• 流量控制：當(dāng)接收方來不及處理發(fā)送方的數(shù)據(jù)，能通過滑動窗口，提示發(fā)送方降低發(fā)送的速率，防止包丟失
• 擁塞控制：當(dāng)網(wǎng)絡(luò)擁塞時，通過擁塞窗口，減少數(shù)據(jù)的發(fā)送，防止包丟失

1）確認(rèn)應(yīng)答機(jī)制

確認(rèn)應(yīng)答機(jī)制

接收端收到一條報(bào)文后，向發(fā)送端發(fā)送一條確認(rèn)ACK，此 ACK 的作用就是告訴發(fā)送端：接收端已經(jīng)成功的收到了消息，并且希望收到下一條報(bào)文的序列號是什么。
這個ACK確認(rèn)號就是期望的下一個報(bào)文的序號。每一個 ACK 都帶有對應(yīng)的確認(rèn)序列號，意思是告訴發(fā)送者，我們已經(jīng)收到了哪些數(shù)據(jù)，下一個發(fā)送數(shù)據(jù)應(yīng)該從哪里開始。 如上圖，主機(jī) A 給主機(jī) B 發(fā)送了 1-1000 的數(shù)據(jù)，ACK 應(yīng)答，攜帶了 1001 序列號。告訴主機(jī) A，我已經(jīng)接受到了 1-1000 數(shù)據(jù)，下一次你從 1001 開始發(fā)送數(shù)據(jù)。

2） 超時重傳

超時重傳

ACK丟失

超時重發(fā)的時間如何確定？

這個時間的長短，隨著網(wǎng)絡(luò)環(huán)境的不同是有差異的。
如果超時時間設(shè)的太長，會影響整體的重傳效率。如果超時時間設(shè)的太短，有可能會頻繁發(fā)送重復(fù)的包。
TCP為了保證無論在任何環(huán)境下都能比較高性能的通信，因此會動態(tài)計(jì)算這個最大超時時間。Linux 中超時時間以500ms為一個單位進(jìn)行控制，每次判定超時重發(fā)的超時時間都是500ms的整數(shù)倍。如果重發(fā)一次之后，仍然得不到應(yīng)答，等待2500ms后再進(jìn)行重傳。如果仍然得不到應(yīng)答，等待4500ms進(jìn)行重傳。依次類推，以指數(shù)形式遞增，當(dāng)累計(jì)到一定的重傳次數(shù)，TCP認(rèn)為網(wǎng)絡(luò)或者對端主機(jī)出現(xiàn)異常，強(qiáng)制關(guān)閉連接。

3）流量控制

流量控制(Flow Control)：TCP支持根據(jù)接收端的處理能力，來決定發(fā)送端的發(fā)送速度
接收端處理數(shù)據(jù)的速度是有限的，如果發(fā)送端發(fā)的太快，導(dǎo)致接收端的緩沖區(qū)被裝滿，這個時候如果發(fā)送端繼續(xù)發(fā)送，就會造成丟包，然后引起丟包重傳等等一系列連鎖反應(yīng)。

實(shí)現(xiàn)過程：

• 接收端將自己可以接收的緩沖區(qū)大小放入 TCP 首部中窗口大小字段，通過ACK確認(rèn)報(bào)文通知發(fā)送端緩沖區(qū)大小
  • 窗口大小字段越大，說明網(wǎng)絡(luò)的吞吐量越高，接收端一旦發(fā)現(xiàn)自己的緩沖區(qū)快滿了，就會將窗口大小設(shè)置成一個更小的值通知給發(fā)送端
• 發(fā)送端接收到這個窗口后，就會減慢自己的發(fā)送速度
• 如果接收端緩沖區(qū)滿了， 就會將窗口置為0。這時發(fā)送方不再發(fā)送數(shù)據(jù)，但是需要定期發(fā)送一個窗口探測數(shù)據(jù)段，使接收端把窗口大小告訴發(fā)送端。
  減慢

4）擁塞控制

雖然TCP有了滑動窗口能夠高效可靠的發(fā)送大量的數(shù)據(jù)，但是如果在剛開始階段就發(fā)送大量的數(shù)據(jù)，仍然可能引發(fā)問題，因?yàn)榫W(wǎng)絡(luò)上有很多的計(jì)算機(jī)，可能當(dāng)前的網(wǎng)絡(luò)狀態(tài)就已經(jīng)比較擁堵，在不清楚當(dāng)前網(wǎng)絡(luò)狀態(tài)下，貿(mào)然發(fā)送大量的數(shù)據(jù)是很有可能引起雪上加霜的，造成網(wǎng)絡(luò)更加堵塞。

TCP 引入慢啟動機(jī)制，先發(fā)少量的數(shù)據(jù)探探路，摸清當(dāng)前的網(wǎng)絡(luò)擁堵狀態(tài)，再決定按照多大的速度傳輸數(shù)據(jù)。

擁塞控制

圖中的cwnd為擁塞窗口，在發(fā)送開始的時候定義擁塞窗口大小為 1，每次收到一個 ACK 應(yīng)答擁塞窗口加1。每次發(fā)送數(shù)據(jù)包的時候，將擁塞窗口和接收端主機(jī)反饋的窗口大小做比較，取較小的值作為實(shí)際發(fā)送的窗口。像上面這樣的擁塞窗口增長速度，是指數(shù)級別的。

擁塞窗口

5）擁塞控制與流量控制的區(qū)別

擁塞控制：是防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，可以使網(wǎng)絡(luò)中的路由器或鏈路不致過載，是一個全局性的過程。
流量控制：是點(diǎn)對點(diǎn)通信量的控制，是一個端到端的問題，主要就是權(quán)衡發(fā)送端發(fā)送數(shù)據(jù)的速率，以便接收端來得及接收。

4. 三次握手

在正常情況下, TCP 要經(jīng)過三次握手建立連接，四次揮手斷開連接。

1）三次握手目的

三次握手其實(shí)就是指建立一個TCP連接時，需要客戶端和服務(wù)器總共發(fā)送3個包。
進(jìn)行三次握手的主要作用就是為了：
1）確認(rèn)雙方的接收能力和發(fā)送能力是否正常
2）指定自己的初始化序列號為后面的可靠性傳送做準(zhǔn)備。
實(shí)質(zhì)上就是連接服務(wù)器指定端口，建立TCP連接，并同步連接雙方的序列號和確認(rèn)號，交換TCP窗口大小信息。

2）三次握手過程

剛開始客戶端處于 Closed 的狀態(tài)，服務(wù)端處于 Listen 狀態(tài)。

三次握手

3次握手簡要過程：

• A向B發(fā)送連接請求，并帶有同步序列號SYN ———— A:我想和你通訊
• B收到連接請求并同意，給A發(fā)送確認(rèn)應(yīng)答ACK和同步序列號(SYN)標(biāo)志位的數(shù)據(jù)段響應(yīng) ———— B:同意和你通訊
• A收到應(yīng)答消息后，再給B發(fā)送一個確認(rèn)應(yīng)答ACK，確認(rèn)已經(jīng)收到B的消息了 ———— A:我收到你的同意消息了
  目的：若是2次握手，阻塞已失效的連接請求報(bào)文段突然又傳到服務(wù)端B，B收到就建立連接，一直監(jiān)聽消息，浪費(fèi)資源

3）為什么需要三次握手，兩次不行嗎？

先弄明白三次握手的目的是什么，能不能只用兩次握手來達(dá)到同樣的目的。
第一次握手：客戶端發(fā)送網(wǎng)絡(luò)包，服務(wù)端收到了。
服務(wù)端就能得出結(jié)論：客戶端的發(fā)送能力、服務(wù)端的接收能力是正常的。
第二次握手：服務(wù)端發(fā)包，客戶端收到了。
客戶端就能得出結(jié)論：服務(wù)端的接收、發(fā)送能力，客戶端的接收、發(fā)送能力是正常的。不過此時服務(wù)器并不能確認(rèn)客戶端的接收能力是否正常。
第三次握手：客戶端發(fā)包，服務(wù)端收到了。
服務(wù)端就能得出結(jié)論：客戶端的接收、發(fā)送能力正常，服務(wù)器自己的發(fā)送、接收能力也正常。
因此，需要三次握手才能確認(rèn)雙方的接收與發(fā)送能力是否正常。

試想如果是用兩次握手，則會出現(xiàn)下面這種情況：

第1次：如客戶端發(fā)出連接請求，但因連接請求報(bào)文丟失而未收到確認(rèn)
第2次：于是客戶端再重傳一次連接請求，后來收到了確認(rèn)，建立了連接。數(shù)據(jù)傳輸完畢后，就釋放了連接
重點(diǎn)：客戶端共發(fā)出了兩個連接請求報(bào)文段，其中第一個丟失，第二個到達(dá)了服務(wù)端，但是第一個丟失的報(bào)文段只是在某些網(wǎng)絡(luò)結(jié)點(diǎn)長時間滯留了，延誤到連接釋放以后的某個時間才到達(dá)服務(wù)端，此時服務(wù)端誤認(rèn)為客戶端又發(fā)出一次新的連接請求，于是就向客戶端發(fā)出確認(rèn)報(bào)文段，同意建立連接，不采用三次握手，只要服務(wù)端發(fā)出確認(rèn)，就建立新的連接了，此時客戶端忽略服務(wù)端發(fā)來的確認(rèn)，也不發(fā)送數(shù)據(jù)，則服務(wù)端一致等待客戶端發(fā)送數(shù)據(jù)，浪費(fèi)資源。

4）三次握手過程中可以攜帶數(shù)據(jù)嗎？

第一次、第二次握手不可以攜帶數(shù)據(jù)；第三次握手的時候，是可以攜帶數(shù)據(jù)的。

假如第一次握手可以攜帶數(shù)據(jù)的話，如果有人要惡意攻擊服務(wù)器，那他每次都在第一次握手中的 SYN 報(bào)文中放入大量的數(shù)據(jù)。因?yàn)楣粽吒揪筒焕矸?wù)器的接收、發(fā)送能力是否正常，然后瘋狂著重復(fù)發(fā) SYN 報(bào)文的話，這會讓服務(wù)器花費(fèi)很多時間、內(nèi)存空間來接收這些報(bào)文。

所以第一次握手不可以放數(shù)據(jù)，原因就是會讓服務(wù)器更加容易受到攻擊了。
而對于第三次的話，此時客戶端已經(jīng)處于 ESTABLISHED 狀態(tài)。對于客戶端來說，他已經(jīng)建立起連接了，并且也已經(jīng)知道服務(wù)器的接收、發(fā)送能力是正常的了，所以能攜帶數(shù)據(jù)也沒啥毛病。

5. 四次揮手

1）四次揮手過程

• 終止一個TCP連接要經(jīng)過四次揮手，這由TCP的半關(guān)閉（half-close）造成的。
• TCP半關(guān)閉，其實(shí)就是TCP提供了連接的一端在結(jié)束它的發(fā)送后還能接收來自另一端數(shù)據(jù)的能力。
• TCP 連接的拆除需要發(fā)送四個包，因此稱為四次揮手(Four-way handshake)
• 客戶端或服務(wù)器均可主動發(fā)起揮手動作（即斷開連接）。

四次揮手

第一次揮手：客戶端發(fā)出連接釋放報(bào)文段（FIN=1，序號seq=u），并停止再發(fā)送數(shù)據(jù)，主動關(guān)閉TCP連接，進(jìn)入FIN_WAIT1（終止等待1）狀態(tài)，等待服務(wù)端的確認(rèn)。
第二次揮手：服務(wù)端收到FIN連接釋放報(bào)文段后即發(fā)出ACK確認(rèn)報(bào)文段（ACK=1，確認(rèn)號ack=u+1，序號seq=v），服務(wù)端進(jìn)入CLOSE_WAIT（關(guān)閉等待）狀態(tài)，此時的TCP處于半關(guān)閉狀態(tài)，客戶端到服務(wù)端的連接釋放?？蛻舳耸盏椒?wù)端的確認(rèn)后，進(jìn)入FIN_WAIT2（終止等待2）狀態(tài)，等待服務(wù)端發(fā)出的連接釋放報(bào)文段。
第三次揮手：如果服務(wù)端也想斷開連接了，服務(wù)端發(fā)出連接釋放報(bào)文段（FIN=1，ACK=1，序號seq=w，確認(rèn)號ack=u+1），服務(wù)端進(jìn)入LAST_ACK（最后確認(rèn)）狀態(tài)，等待客戶端的確認(rèn)。
第四次揮手：客戶端收到服務(wù)端的FIN連接釋放報(bào)文段后，對此發(fā)出ACK確認(rèn)報(bào)文段（ACK=1，seq=u+1，ack=w+1），客戶端進(jìn)入TIME_WAIT（時間等待）狀態(tài)。此時TCP未釋放掉，需要經(jīng)過時間等待計(jì)時器設(shè)置的時間2MSL后，客戶端才進(jìn)入CLOSED狀態(tài)。

收到一個FIN只意味著在這一方向上沒有數(shù)據(jù)流動?？蛻舳藞?zhí)行主動關(guān)閉并進(jìn)入TIME_WAIT是正常的，服務(wù)端通常執(zhí)行被動關(guān)閉，不會進(jìn)入TIME_WAIT狀態(tài)。

四次揮手簡要過程：

由于TCP連接是全雙工的，因此每個方向必須單獨(dú)關(guān)閉

• A給B發(fā)送FIN，停止A向B發(fā)送數(shù)據(jù)，但此時A還是能接收B的數(shù)據(jù) ———— A：我不會再給你發(fā)數(shù)據(jù)了
• B收到A的消息，給A發(fā)送確認(rèn)ACK消息 ———— B：我知道了
• B給A發(fā)送FIN，停止B向A發(fā)送數(shù)據(jù) ———— B：我也不會再給你發(fā)數(shù)據(jù)了
• A收到B的消息，給B發(fā)送確認(rèn)ACK消息 ———— A：我知道了

2）揮手為什么需要四次？

關(guān)閉連接時，當(dāng)服務(wù)端收到FIN報(bào)文時，很可能并不會立即關(guān)閉SOCKET，所以只能先回復(fù)一個ACK報(bào)文，告訴客戶端，“你發(fā)的FIN報(bào)文我收到了”。只有等到服務(wù)端所有的報(bào)文都發(fā)送完了，服務(wù)端才會發(fā)送FIN報(bào)文，因此不能一起發(fā)送。故需要四次揮手。

3）四次揮手釋放連接時，等待2MSL的意義?

MSL：是“最長報(bào)文段壽命”，它是任何報(bào)文在網(wǎng)絡(luò)上存在的最長時間，超過這個時間報(bào)文將被丟棄。
等待2MSL的理由：

• 保證客戶端發(fā)送的最后一個ACK報(bào)文段能夠到達(dá)服務(wù)端。
  • 若客戶端發(fā)送的最后一個ACK報(bào)文段丟失，使得服務(wù)端收不到對已發(fā)送的FIN+ACK報(bào)文段的確認(rèn)，服務(wù)端超時重傳FIN+ACK報(bào)文段，而客戶端能在2MSL時間內(nèi)收到這個重傳的FIN+ACK報(bào)文段，接著客戶端重傳一次確認(rèn)，重新啟動2MSL計(jì)時器，最后客戶端和服務(wù)端都進(jìn)入到CLOSED狀態(tài)，
  • 若客戶端不等待2MSL時間，而是發(fā)送完ACK報(bào)文段后立即釋放連接，則無法收到服務(wù)端重傳的FIN+ACK報(bào)文段，服務(wù)端則會一直重傳釋放連接的FIN+ACK報(bào)文段，無法正常進(jìn)入到CLOSED狀態(tài)。
• 防止“已失效的連接請求報(bào)文段”出現(xiàn)在本連接中。
  • 客戶端在發(fā)送完最后一個ACK報(bào)文段后，再經(jīng)過2MSL，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失，使下一個新的連接中不會出現(xiàn)這種舊的連接請求報(bào)文段。

4）為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL才能返回到CLOSE狀態(tài)？

理論上，四個報(bào)文都發(fā)送完畢，就可以直接進(jìn)入CLOSE狀態(tài)了，但是可能網(wǎng)絡(luò)是不可靠的，有可能最后一個ACK丟失。所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報(bào)文。

6. TCP全雙工模式

TCP是全雙工工作模式
全雙工： 指可以同時進(jìn)行信號的雙向傳輸（A→B且B→A）。指A→B的同時B→A，是瞬時同步的。
半雙工：指一個時間內(nèi)只有一個方向的信號傳輸（A→B或B→A）

三、TCP和UDP的區(qū)別

TCP：傳輸控制協(xié)議，UDP：用戶數(shù)據(jù)報(bào)協(xié)議
TCP和UDP都是傳輸層協(xié)議

區(qū)別：

• TCP 面向連接（如打電話要先撥號建立連接）；UDP 是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接
• TCP 提供可靠的服務(wù)，通過 TCP 連接傳送的數(shù)據(jù)，無差錯，不丟失，不重復(fù)，且按序到達(dá)；
  UDP 盡最大努力交付，即不保證可靠交付，可能丟包
• TCP 面向字節(jié)流的服務(wù)，UDP 是面向報(bào)文的服務(wù)
• TCP有流量控制和擁塞控制，UDP沒有，網(wǎng)絡(luò)擁堵不會影響發(fā)送端的發(fā)送速率，因此UDP具有較好的實(shí)時性，工作效率較TCP協(xié)議高
• TCP 連接只能是一對一；UDP 支持一對一，一對多，多對一和多對多的通信
• TCP所需資源多，首部開銷 20 字節(jié)；UDP 的首部開銷小，只有 8 個字節(jié)
• TCP 的邏輯通信信道是全雙工的可靠信道；UDP 則是不可靠信道

TCP應(yīng)用：一般用于文件傳輸、發(fā)送接收郵件，如FTP(文件傳輸協(xié)議)、HTTP
UDP應(yīng)用：即時通訊、網(wǎng)絡(luò)語音、視頻電話、實(shí)時游戲

四、HTTP

1. HTTP簡介

1）定義

HTTP是超文本傳輸協(xié)議，它是基于 TCP 協(xié)議的應(yīng)用層傳輸協(xié)議，簡單來說就是客戶端和服務(wù)端進(jìn)行數(shù)據(jù)傳輸?shù)囊环N規(guī)則。

2）特點(diǎn)

• 傳輸效率高：
  • 無連接：交換HTTP報(bào)文前，不需要建立HTTP連接
  • 無狀態(tài)：數(shù)據(jù)傳輸過程中，不保存任何歷史狀態(tài)和信息，因此簡化服務(wù)器的設(shè)計(jì)，使得更容易支持大量并發(fā)的HTTP請求
  • 傳輸格式簡單：請求時，只需傳送請求方法和路徑
• 傳輸可靠性高：采用TCP作為運(yùn)輸層協(xié)議（TCP面向連接、可靠傳輸，交換報(bào)文前需要建立TCP連接）
• 兼容性好：支持B/S、C/S模式
• 靈活性高：HTTP允許傳輸任意類型的數(shù)據(jù)對象

http總結(jié)

2. HTTP工作方式

HTTP協(xié)議采用 【請求/響應(yīng)】 的工作方式
具體流程：
1）服務(wù)器不斷監(jiān)聽TCP端口80
2）客戶端發(fā)送【建立連接】請求
3）雙方建立TCP連接
4）客戶端發(fā)送頁面請求：【形式=HTTP請求報(bào)文】
5）服務(wù)器返回頁面請求的響應(yīng)結(jié)果：【形式=HTTP響應(yīng)報(bào)文】
6）關(guān)閉TCP連接

http工作方式

3. HTTP報(bào)文

HTTP在應(yīng)用層交互數(shù)據(jù)的方式 ：報(bào)文

HTTP的報(bào)文分為：請求報(bào)文（發(fā)送請求）、響應(yīng)報(bào)文（響應(yīng)請求）

3.1 請求報(bào)文格式

報(bào)文結(jié)構(gòu)

1）請求行

作用：聲明 請求方法 、主機(jī)域名、資源路徑、協(xié)議版本
結(jié)構(gòu)：請求行的組成 = 請求方法 + 請求路徑 + 協(xié)議版本

GET /example.html HTTP/1.1 

備注：空格不能省

請求行

get/post區(qū)別

示例： 請求報(bào)文采用GET方法、

• URL地址 = http://www.tsinghua.edu.cn/chn/yxsz/index.htm；
• HTTP1.1版本

則請求行是：GET /chn/yxsz/index.htm HTTP/1.1

2）請求頭

作用：聲明客戶端、服務(wù)器 / 報(bào)文的部分信息
使用方式：采用header(字段名)：value(值)的方式
常用請求頭：

• 請求和響應(yīng)報(bào)文的通用Header
  header

• 常見請求Header
  header

舉例： (URL地址：http://www.tsinghua.edu.cn/chn/yxsz/index.htm）
Host：www.tsinghua.edu.cn (表示主機(jī)域名）
User - Agent：Mozilla/5.0 (表示用戶代理是使用Netscape瀏覽器）

3）請求體

作用：存放需發(fā)送給服務(wù)器的數(shù)據(jù)信息，可選部分，如 GET請求就無請求數(shù)據(jù)

請求體

3.2 HTTP響應(yīng)報(bào)文

1）報(bào)文結(jié)構(gòu)

響應(yīng)報(bào)文

其中，響應(yīng)頭、響應(yīng)體與請求報(bào)文的請求頭、請求體類似
請求報(bào)文和響應(yīng)報(bào)文最大的不同在于狀態(tài)行與請求行

2）狀態(tài)行

組成：狀態(tài)行有協(xié)議版本、狀態(tài)碼、狀態(tài)信息組成，其中空格不能省

狀態(tài)行

具體介紹

狀態(tài)行示例：

• HTTP/1.1 202 Accepted(接受)
• HTTP/1.1 404 Not Found(找不到)

3）響應(yīng)頭

作用：聲明客戶端、服務(wù)器報(bào)文的部分信息
使用方式：采用header（字段名）：value（值）的方式
常用請求頭：
（1）請求和響應(yīng)報(bào)文的通用Header

header

響應(yīng)header

4）響應(yīng)體

作用：存放需返回給客戶端的數(shù)據(jù)信息
使用方式：和請求體是一致的

響應(yīng)體

5）響應(yīng)報(bào)文總結(jié)

響應(yīng)報(bào)文

4. HTTP1.1和HTTP1.0的區(qū)別

Http1.1 比 Http1.0 多了以下優(yōu)點(diǎn)：

• HTTP1.0默認(rèn)短連接，每次與服務(wù)器交互，都需要新開一個連接
  HTTP1.1默認(rèn)持久連接，只要客戶端服務(wù)端沒有斷開TCP連接，就一直保持連接，可以發(fā)送多次HTTP請求
• 引入更加多的請求頭、響應(yīng)頭：如與身份認(rèn)證、狀態(tài)管理、 Cache緩存等機(jī)制相關(guān)的、HTTP1.0無host字段

5. HTTPS

HTTPS就是安全的HTTP協(xié)議（客戶端與服務(wù)端的傳輸鏈路中進(jìn)行加密）

HTTPS請求過程：

1）認(rèn)證

• 服務(wù)器在使用HTTPS前，需要去CA機(jī)構(gòu)申請數(shù)字證書：數(shù)字證書里包含證書持有者、證書有效期、服務(wù)器公鑰 等信息
• 客戶端請求服務(wù)器時，服務(wù)器返回私鑰加密的證書給客戶端
• 客戶端用CA的公鑰對證書解密，這個時候客戶端會判斷這個證書是否可信/有無篡改（因?yàn)镃A是公信機(jī)構(gòu)，會內(nèi)置到瀏覽器或操作系統(tǒng)中，所以客戶端會有公鑰）

私鑰加密，公鑰解密叫做數(shù)字簽名，這種方式可以查看有無篡改，到這里就解決了認(rèn)證的問題，保證客戶端是在跟真實(shí)的服務(wù)器進(jìn)行通信

認(rèn)證

2）加密

解決了認(rèn)證的問題之后，就要解決加密問題，客戶端與服務(wù)器的通訊內(nèi)容在傳輸中不會泄漏給第三方

• 客戶端從CA拿到數(shù)字證書后，就能拿到服務(wù)端的公鑰
• 客戶端生成一個key作為對稱加密的密鑰，用服務(wù)端的公鑰加密后傳給服務(wù)端
• 服務(wù)端用自己的私鑰解密客戶端的數(shù)據(jù)，得到對稱加密的密鑰
• 此時客戶端和服務(wù)端都有此對稱加密的密鑰了，就可以使用此密鑰發(fā)送和接收消息

https加密過程

HTTP和HTTPS的區(qū)別

http/https區(qū)別

1）安全性：HTTP 明文傳輸，數(shù)據(jù)都是未加密的，安全性較差，HTTPS（SSL+HTTP） 數(shù)據(jù)傳輸過程是加密的，安全性較好。
2）響應(yīng)速度：HTTP 頁面響應(yīng)速度比 HTTPS 快，主要是因?yàn)?HTTP 使用 TCP 三次握手建立連接，客戶端和服務(wù)器需要交換 3 個包，而 HTTPS除了 TCP 的三個包，還要加上 ssl 握手需要的 9 個包，所以一共是 12 個包。
3）耗費(fèi)資源：HTTPS 其實(shí)就是建構(gòu)在 SSL/TLS 之上的 HTTP 協(xié)議，所以，要比較 HTTPS 比 HTTP 要更耗費(fèi)服務(wù)器資源。
4）端口：http 和 https 使用的是完全不同的連接方式，用的端口也不一樣，前者是 80，后者是 443。
5）費(fèi)用：使用 HTTPS 協(xié)議需要到 CA（Certificate Authority，數(shù)字證書認(rèn)證機(jī)構(gòu)） 申請證書，一般免費(fèi)證書較少，因而需要一定費(fèi)用。

五、輸入URL到頁面呈現(xiàn)的過程

1）DNS域名解析：從url中提取出網(wǎng)站域名，使用 DNS 域名解析（域名和服務(wù)器 IP 對應(yīng)關(guān)系保存在 hosts 文件中），找到對應(yīng)服務(wù)器 IP地址
2）建立TCP連接：發(fā)起 TCP三次握手建立連接
3）發(fā)起HTTP請求：建立 tcp 連接后，發(fā)起請求 (包括端口路徑，請求參數(shù)和各種信息)，獲取服務(wù)器資源
4）響應(yīng)HTTP請求：服務(wù)器響應(yīng) http 請求，將資源以http數(shù)據(jù)包封裝，通過網(wǎng)絡(luò)協(xié)議傳輸?shù)角岸?br> 5）渲染：瀏覽器解析渲染頁面
6）TCP關(guān)閉：四次揮手釋放連接
總結(jié)：瀏覽器緩存——>DNS 域名解析——>TCP 連接——>HTTP 請求與響應(yīng)——->DOM 渲染——>TCP 關(guān)閉

DNS域名解析過程：

1）先查看瀏覽器緩存
2）查看操作系統(tǒng)緩存
3）向本地域名服務(wù)器請求查詢
4）本地域名去根域名服務(wù)器查詢
5）本地域名服務(wù)器去頂級域名服務(wù)器查詢
6）本地域名服務(wù)器去權(quán)威域名服務(wù)器查詢

DNS域名解析

六、cookie、session

會話跟蹤是Web程序中常用的技術(shù)，用來跟蹤用戶的整個會話。
常用的會話跟蹤技術(shù)是Cookie與Session。Cookie通過在客戶端記錄信息確定用戶身份，Session通過在服務(wù)器端記錄信息確定用戶身份

理論上，一個用戶的所有請求操作都應(yīng)該屬于同一個會話。但由于HTTP協(xié)議是無狀態(tài)的協(xié)議，一旦數(shù)據(jù)交換完畢，客戶端與服務(wù)器端的連接就會關(guān)閉，再次交換數(shù)據(jù)需要建立新的連接。這就意味著服務(wù)器無法從連接上跟蹤會話。即用戶A購買了一件商品放入購物車內(nèi)，當(dāng)再次購買商品時服務(wù)器已經(jīng)無法判斷該購買行為是屬于用戶A的會話還是用戶B的會話了。要跟蹤該會話，必須引入一種機(jī)制。

共同點(diǎn)：

cookie 和 session 都是用來跟蹤瀏覽器用戶身份的會話方式，即認(rèn)證鑒權(quán)

區(qū)別：

1）存儲位置不同
cookie 數(shù)據(jù)存放在客戶的瀏覽器上；session 數(shù)據(jù)放在服務(wù)器上。
2）隱私安全
cookie 不是很安全，對客戶端是可見的，可以通過分析存放在本地的cookie并進(jìn)行cookie欺騙，所以它是不安全的；
session存儲在服務(wù)器上，對客戶端是透明的，不存在敏感信息泄漏的風(fēng)險。
3）有效期不同：
可以設(shè)置cookie的屬性，達(dá)到使cookie長期有效的效果；
session只需關(guān)閉窗口該session就會失效，因而session不能達(dá)到長期有效的效果。
4）服務(wù)器壓力不同
cookie保管在客戶端，不占用服務(wù)器資源。對于并發(fā)用戶十分多的網(wǎng)站，cookie是很好的選擇。
session是保管在服務(wù)器端的，每個用戶都會產(chǎn)生一個session。假如并發(fā)訪問的用戶十分多，會產(chǎn)生十分多的session，耗費(fèi)大量的內(nèi)存。
5）存儲容量不同：
單個cookie保存的數(shù)據(jù)<=4KB，一個站點(diǎn)最多保存20個Cookie。
對于session來說并沒有上限，但出于對服務(wù)器端的性能考慮，session內(nèi)不要存放過多的東西，并且設(shè)置session刪除機(jī)制。

七、網(wǎng)頁加載慢的原因

1）本地問題：網(wǎng)絡(luò)環(huán)境差、帶寬不足，CPU或者是內(nèi)存被占滿等
2）DNS解析速度慢
3）加載某個資源太慢：資源在第三方網(wǎng)站上、資源太大了、資源使用的域名有問題
4）后端代碼問題：代碼冗余、數(shù)據(jù)庫發(fā)生鎖死、動態(tài)請求時間過長等
5）前端頁面請求的資源過多：請求數(shù)太多、包含大量未經(jīng)處理的圖片
6）前端頁面渲染太慢了

通過F12工具分析是前端還是后端響應(yīng)慢問題：

• 如果服務(wù)器獲取請求到返回的時間長 ———— 后端問題；
• 如果是請求獲取數(shù)據(jù)很快，但是數(shù)據(jù)很多頁面渲染需要時間 ———— 前端問題

八、如何判斷是前端還是后端問題？

通過F12工具分析請求+響應(yīng)：

• 請求url、參數(shù)等問題 ———— 前端問題；
• 響應(yīng)結(jié)果正確 ———— 前端問題
• 響應(yīng)結(jié)果錯誤 ———— 后端問題

九、post和get的區(qū)別？

1.傳送方式：get通過地址欄傳輸，post通過報(bào)文傳輸
2.傳送長度：get參數(shù)有長度限制（受限于url的長度），而post無限制
3.get產(chǎn)生一個TCP數(shù)據(jù)包：瀏覽器將header和data一起發(fā)出去，服務(wù)器響應(yīng)200返回?cái)?shù)據(jù)；
POST產(chǎn)生兩個TCP數(shù)據(jù)包：瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，再發(fā)送data，服務(wù)器響應(yīng)200返回?cái)?shù)據(jù)；
4.get請求參數(shù)會被完整保留在瀏覽歷史記錄里，而post中的參數(shù)不會被保留
5.get：數(shù)據(jù)查詢；post：數(shù)據(jù)添加、修改、刪除

十、接口中常見的返回狀態(tài)碼

• 1xx：信息提示
• 2xx：服務(wù)器成功接收客戶端請求，如200：OK
• 3xx：重定向
• 4xx：客戶端錯誤，404：請求頁面不存在
• 500：服務(wù)端錯誤