TCP

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

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

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

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

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

ARP 解析 IP 中的MAC 地址，MAC 地址由網卡出廠提供

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

物理層將二進制的0和1和電壓高低，光的閃滅和電波的強弱信號進行轉換

鏈路層代表驅動

網絡層

傳輸層

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

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

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

會話層以上分層

TCP/IP 分層中，會話層，表示層，應用層集中在一起

網絡管理通過SNMP協(xié)議

劃重點了?。嬖囎畛柕陌。?/p>

TCP三次握手和四次揮手？

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

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

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

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

四次揮手：

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

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

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

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

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

TCP和UDP的區(qū)別？

仔細閱讀上面?zhèn)鬏攲永飳懙膬热荩藛?？（不懂？不懂背下來?。?**?。?/p>

我們微信聊天時候經常會有這種情況。

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

HTTP

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

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

http傳輸流

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

又來劃重點了啊

HTTP的英文全稱？

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

狀態(tài)碼？

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

2XX 成功

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

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

206 Partial Content，進行范圍請求

3XX 重定向

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

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

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

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

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

4XX 客戶端錯誤

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

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

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

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

5XX 服務器錯誤

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

503 service unavailable，表明服務器暫時處于超負載或正在停機維護，無法處理請求

HTTP協(xié)議格式？

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

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

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

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

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

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

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

輸入地址

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

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

服務器的永久重定向響應

瀏覽器跟蹤重定向地址

服務器處理請求

服務器返回一個 HTTP 響應

瀏覽器顯示 HTML

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

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