TCP

要說http就繞不開tcp，TCP協(xié)議對應(yīng)于傳輸層，而HTTP協(xié)議對應(yīng)于應(yīng)用層，從本質(zhì)上來說，二者沒有可比性。但是，http是基于tcp協(xié)議的。

TCP/IP 協(xié)議分層模型

使用 IP 協(xié)議，IP 協(xié)議基于 IP 轉(zhuǎn)發(fā)分包數(shù)據(jù)

IP 協(xié)議是個不可靠協(xié)議，不會重發(fā)

IP 協(xié)議發(fā)送失敗會使用ICMP協(xié)議通知失敗

ARP 解析 IP 中的MAC 地址，MAC 地址由網(wǎng)卡出廠提供

IP 還隱含鏈路層的功能，不管雙方底層的鏈路層是啥，都能通信

物理層將二進(jìn)制的0和1和電壓高低，光的閃滅和電波的強(qiáng)弱信號進(jìn)行轉(zhuǎn)換

鏈路層代表驅(qū)動

網(wǎng)絡(luò)層

傳輸層

通用的 TCP 和 UDP 協(xié)議

TCP 協(xié)議面向有連接，能正確處理丟包，傳輸順序錯亂的問題，但是為了建立與斷開連接，需要至少7次的發(fā)包收包，資源浪費

UDP 面向無連接，不管對方有沒有收到，如果要得到通知，需要通過應(yīng)用層

會話層以上分層

TCP/IP 分層中，會話層，表示層，應(yīng)用層集中在一起

網(wǎng)絡(luò)管理通過SNMP協(xié)議

劃重點了啊（面試最常問的啊）

TCP三次握手和四次揮手？

被問爛了的問題了，這里不詳細(xì)講了，三次握手：

客戶端–發(fā)送帶有SYN標(biāo)志的數(shù)據(jù)包–一次握手–服務(wù)端

服務(wù)端–發(fā)送帶有SYN/ACK標(biāo)志的數(shù)據(jù)包–二次握手–客戶端

客戶端–發(fā)送帶有帶有ACK標(biāo)志的數(shù)據(jù)包–三次握手–服務(wù)端

四次揮手：

客戶端-發(fā)送一個FIN，用來關(guān)閉客戶端到服務(wù)器的數(shù)據(jù)傳送

服務(wù)器-收到這個FIN，它發(fā)回一個ACK，確認(rèn)序號為收到的序號加1 。和SYN一樣，一個FIN將占用一個序號

服務(wù)器-關(guān)閉與客戶端的連接，發(fā)送一個FIN給客戶端

客戶端-發(fā)回ACK報文確認(rèn)，并將確認(rèn)序號設(shè)置為收到序號加1

還不懂的童鞋，去找別人的文章好好看看！

TCP和UDP的區(qū)別？

仔細(xì)閱讀上面?zhèn)鬏攲永飳懙膬?nèi)容，懂了嗎？（不懂？不懂背下來啊，***！）

我們微信聊天時候經(jīng)常會有這種情況。

是不是感同身受，這種情況就是對方用了TCP協(xié)議來聊天，要經(jīng)過--在嗎？--在--巴拉巴拉，才能成功的傳遞信息。而如果對方使用UDP，則會有事直接說，不管我收沒收到。（以后找我請用UDP協(xié)議，著急直接打電話！）

HTTP

Http協(xié)議是建立在TCP協(xié)議基礎(chǔ)之上的，當(dāng)瀏覽器需要從服務(wù)器獲取網(wǎng)頁數(shù)據(jù)的時候，會發(fā)出一次Http請求。Http會通過TCP建立起一個到服務(wù)器的連接通道，當(dāng)本次請求需要的數(shù)據(jù)完畢后，Http會立即將TCP連接斷開，這個過程是很短的。所以Http連接是一種短連接，是一種無狀態(tài)的連接。

所謂的無狀態(tài)，是指瀏覽器每次向服務(wù)器發(fā)起請求的時候，不是通過一個連接，而是每次都建立一個新的連接。如果是一個連接的話，服務(wù)器進(jìn)程中就能保持住這個連接并且在內(nèi)存中記住一些信息狀態(tài)。而每次請求結(jié)束后，連接就關(guān)閉，相關(guān)的內(nèi)容就釋放了，所以記不住任何狀態(tài)，成為無狀態(tài)連接。

http傳輸流

發(fā)送端在層與層間傳輸數(shù)據(jù)時，沒經(jīng)過一層都會被加上首部信息，接收端每經(jīng)過一層都會刪除一條首部

又來劃重點了啊

HTTP的英文全稱？

開玩笑的，這個顯然不是重點，但是不排除有人會去問，還是要知道的：超文本傳輸協(xié)議（HyperText Transfer Protocol）

狀態(tài)碼？

狀態(tài)碼就那些，常用的記住就行了：

2XX 成功

200 OK，表示從客戶端發(fā)來的請求在服務(wù)器端被正確處理

204 No content，表示請求成功，但響應(yīng)報文不含實體的主體部分

206 Partial Content，進(jìn)行范圍請求

3XX 重定向

301 moved permanently，永久性重定向，表示資源已被分配了新的 URL

302 found，臨時性重定向，表示資源臨時被分配了新的 URL

303 see other，表示資源存在著另一個 URL，應(yīng)使用 GET 方法丁香獲取資源

304 not modified，表示服務(wù)器允許訪問資源，但因發(fā)生請求未滿足條件的情況

307 temporary redirect，臨時重定向，和302含義相同

4XX 客戶端錯誤

400 bad request，請求報文存在語法錯誤

401 unauthorized，表示發(fā)送的請求需要有通過 HTTP 認(rèn)證的認(rèn)證信息

403 forbidden，表示對請求資源的訪問被服務(wù)器拒絕

404 not found，表示在服務(wù)器上沒有找到請求的資源

5XX 服務(wù)器錯誤

500 internal sever error，表示服務(wù)器端在執(zhí)行請求時發(fā)生了錯誤

503 service unavailable，表明服務(wù)器暫時處于超負(fù)載或正在停機(jī)維護(hù)，無法處理請求

HTTP協(xié)議格式？

HTTP的請求和響應(yīng)的消息協(xié)議是一樣的，分為三個部分，起始行、消息頭和消息體。這三個部分以CRLF作為分隔符。最后一個消息頭有兩個CRLF，用來表示消息頭部的結(jié)束。

HTTP請求的起始行稱為請求行，形如GET /index.html HTTP/1.1

HTTP響應(yīng)的起始行稱為狀態(tài)行，形如200 ok

消息頭部有很多鍵值對組成，多個鍵值對之間使用CRLF作為分隔符，也可以完全沒有鍵值對。形如Content-Encoding: gzip消息體是一個字符串，字符串的長度是由消息頭部的Content-Length鍵指定的。如果沒有Content-Length字段說明沒有消息體，譬如GET請求就是沒有消息體的，POST請求的消息體一般用來放置表單數(shù)據(jù)。GET請求的響應(yīng)返回的頁面內(nèi)容也是放在消息體里面的。我們平時調(diào)用API返回的JSON內(nèi)容都是放在消息體里面的。

HTTP的無狀態(tài)性？

所謂HTTP協(xié)議的無狀態(tài)性是指服務(wù)器的協(xié)議層無需為不同的請求之間建立任何相關(guān)關(guān)系，它特指的是協(xié)議層的無狀態(tài)性。但是這并不代表建立在HTTP協(xié)議之上的應(yīng)用程序就無法維持狀態(tài)。應(yīng)用層可以通過會話Session來跟蹤用戶請求之間的相關(guān)性，服務(wù)器會為每個會話對象綁定一個唯一的會話ID，瀏覽器可以將會話ID記錄在本地緩存LocalStorage或者Cookie，在后續(xù)的請求都帶上這個會話ID，服務(wù)器就可以為每個請求找到相應(yīng)的會話狀態(tài)。

輸入url到頁面加載都發(fā)生了什么事情？（最最常問的來了）

輸入地址

瀏覽器查找域名的 IP 地址這一步包括 DNS 具體的查找過程，包括：瀏覽器緩存->系統(tǒng)緩存->路由器緩存...

瀏覽器向 web 服務(wù)器發(fā)送一個 HTTP 請求

服務(wù)器的永久重定向響應(yīng)

瀏覽器跟蹤重定向地址

服務(wù)器處理請求

服務(wù)器返回一個 HTTP 響應(yīng)

瀏覽器顯示 HTML

瀏覽器發(fā)送請求獲取嵌入在 HTML 中的資源（如圖片、音頻、視頻、CSS、JS等等）

瀏覽器發(fā)送異步請求