1. OSI 7層協(xié)議，會畫出來，知道主要幾層的各自作用

OSI.jpg

1. 應(yīng)用層（數(shù)據(jù)）：確定進(jìn)程之間通信的性質(zhì)以滿足用戶需要以及提供網(wǎng)絡(luò)與用戶應(yīng)用
2. 表示層（數(shù)據(jù)）：主要解決擁護(hù)信息的語法表示問題，如加密解密
3. 會話層（數(shù)據(jù)）：提供包括訪問驗證和會話管理在內(nèi)的建立和維護(hù)應(yīng)用之間通信的機(jī)制，如服務(wù)器驗證用戶登錄便是由會話層完成的
4. 傳輸層（段）：實現(xiàn)網(wǎng)絡(luò)不同主機(jī)上用戶進(jìn)程之間的數(shù)據(jù)通信，可靠
   與不可靠的傳輸，傳輸層的錯誤檢測，流量控制等
5. 網(wǎng)絡(luò)層（包）：提供邏輯地址（IP）、選路，數(shù)據(jù)從源端到目的端的
   傳輸
6. 數(shù)據(jù)鏈路層（幀）：將上層數(shù)據(jù)封裝成幀，用MAC地址訪問媒介，錯誤檢測與修正
7. 物理層（比特流）：設(shè)備之間比特流的傳輸，物理接口，電氣特性等

2. TCP/IP 4層協(xié)議

TCP/IP.jpg

1. 應(yīng)用層：TCP/IP模型將OSI參考模型中的會話層和表示層的功能合并到應(yīng)用層實現(xiàn)。應(yīng)用層面向不同的網(wǎng)絡(luò)應(yīng)用引入了不同的應(yīng)用層協(xié)議。其中，有基于TCP協(xié)議的，如文件傳輸協(xié)議（File Transfer Protocol，F(xiàn)TP）、虛擬終端協(xié)議（TELNET）、超文本鏈接協(xié)議（Hyper Text Transfer Protocol，HTTP），也有基于UDP協(xié)議的。
2. 傳輸層：在TCP/IP模型中，傳輸層的功能是使源端主機(jī)和目標(biāo)端主機(jī)上的對等實體可以進(jìn)行會話。在傳輸層定義了兩種服務(wù)質(zhì)量不同的協(xié)議。即：傳輸控制協(xié)議TCP（transmission control protocol）和用戶數(shù)據(jù)報協(xié)議UDP（user datagram protocol)
3. 網(wǎng)絡(luò)互連層：網(wǎng)絡(luò)互連層是整個TCP/IP協(xié)議棧的核心。它的功能是把分組發(fā)往目標(biāo)網(wǎng)絡(luò)或主機(jī)。同時，為了盡快地發(fā)送分組，可能需要沿不同的路徑同時進(jìn)行分組傳遞。因此，分組到達(dá)的順序和發(fā)送的順序可能不同，這就需要上層必須對分組進(jìn)行排序。
   網(wǎng)絡(luò)互連層定義了分組格式和協(xié)議，即IP協(xié)議（Internet Protocol）?！　?br> 網(wǎng)絡(luò)互連層除了需要完成路由的功能外，也可以完成將不同類型的網(wǎng)絡(luò)（異構(gòu)網(wǎng)）互連的任務(wù)。除此之外，網(wǎng)絡(luò)互連層還需要完成擁塞控制的功能
4. 主機(jī)到網(wǎng)絡(luò)層：實際上TCP/IP參考模型沒有真正描述這一層的實現(xiàn)，只是要求能夠提供給其上層-網(wǎng)絡(luò)互連層一個訪問接口，以便在其上傳遞IP分組。由于這一層次未被定義，所以其具體的實現(xiàn)方法將隨著網(wǎng)絡(luò)類型的不同而不同

3 TCP/UDP

TCP協(xié)議是一個面向連接的、可靠的協(xié)議。它將一臺主機(jī)發(fā)出的字節(jié)流無差錯地發(fā)往互聯(lián)網(wǎng)上的其他主機(jī)。在發(fā)送端，它負(fù)責(zé)把上層傳送下來的字節(jié)流分成報文段并傳遞給下層。在接收端，它負(fù)責(zé)把收到的報文進(jìn)行重組后遞交給上層。TCP協(xié)議還要處理端到端的流量控制，以避免緩慢接收的接收方?jīng)]有足夠的緩沖區(qū)接收發(fā)送方發(fā)送的大量數(shù)據(jù)。

UDP協(xié)議是一個不可靠的、無連接協(xié)議，主要適用于不需要對報文進(jìn)行排序和流量控制的場合。

1. TCP面向連接，UDP面向無鏈接
2. TCP面向報文，UDP面向字節(jié)流
3. TCP提供可靠傳輸服務(wù)（數(shù)據(jù)順序、正確性），UDP傳輸不可靠
4. TCP協(xié)議傳輸速度慢，UDP協(xié)議傳輸速度快
5. TCP協(xié)議對系統(tǒng)資源要求多（頭部開銷大），UDP協(xié)議要求少

4 TCP3次握手，4次揮手

TCP握手揮手.png

握手

1. 第一次握手：建立連接?？蛻舳税l(fā)送連接請求報文段，將SYN位置為1，Sequence Number為x；然后，客戶端進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器的確認(rèn)；
2. 第二次握手：服務(wù)器收到SYN報文段。服務(wù)器收到客戶端的SYN報文段，需要對這個SYN報文段進(jìn)行確認(rèn)，設(shè)置Acknowledgment Number為x+1(Sequence Number+1)；同時，自己自己還要發(fā)送SYN請求信息，將SYN位置為1，Sequence Number為y；服務(wù)器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中，一并發(fā)送給客戶端，此時服務(wù)器進(jìn)入SYN_RECV狀態(tài)；
3. 第三次握手：客戶端收到服務(wù)器的SYN+ACK報文段。然后將Acknowledgment Number設(shè)置為y+1，向服務(wù)器發(fā)送ACK報文段，這個報文段發(fā)送完畢以后，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)，完成TCP三次握手。

揮手

1. 第一次揮手：主機(jī)1（可以是客戶端，也可以是服務(wù)器端），設(shè)置Sequence Number和Acknowledgment Number，向主機(jī)2發(fā)送一個FIN報文段；此時，主機(jī)1進(jìn)入FIN_WAIT_1狀態(tài)；這表示主機(jī)1沒有數(shù)據(jù)要發(fā)送給主機(jī)2了；
2. 第二次揮手：主機(jī)2收到了主機(jī)1發(fā)送的FIN報文段，向主機(jī)1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機(jī)1進(jìn)入FIN_WAIT_2狀態(tài)；主機(jī)2告訴主機(jī)1，我“同意”你的關(guān)閉請求；
3. 第三次揮手：主機(jī)2向主機(jī)1發(fā)送FIN報文段，請求關(guān)閉連接，同時主機(jī)2進(jìn)入LAST_ACK狀態(tài)；
4. 第四次揮手：主機(jī)1收到主機(jī)2發(fā)送的FIN報文段，向主機(jī)2發(fā)送ACK報文段，然后主機(jī)1進(jìn)入TIME_WAIT狀態(tài)；主機(jī)2收到主機(jī)1的ACK報文段以后，就關(guān)閉連接；此時，主機(jī)1等待2MSL后依然沒有收到回復(fù)，則證明Server端已正常關(guān)閉，那好，主機(jī)1也可以關(guān)閉連接了。

5 為什么建立連接時是三次握手，兩次行不行

不行。只有三次握手過程，客戶端能夠確認(rèn)雙方的發(fā)送和接收功能正常，服務(wù)端能夠確認(rèn)雙方的發(fā)送和接收功能正常。

6 四次揮手能夠變成三次嗎

請注意在服務(wù)器接收到客戶端的斷開請求時，服務(wù)器向客戶端發(fā)送的數(shù)據(jù)可能還沒有發(fā)送完。如果是三次揮手的話，那么要等到服務(wù)器將數(shù)據(jù)發(fā)送完，再發(fā)送給客戶端一個ACK，那么就麻煩了。因為客戶端遲遲接收不到服務(wù)器的確認(rèn)，那么就會不斷地發(fā)送斷開請求，這種情況使我們不希望出現(xiàn)的，因為對服務(wù)器和客戶端都是一種不好的情況。但是如果是四次揮手的話，服務(wù)器一接收到斷開請求，立即回復(fù)給客戶端一個ACK，那么客戶端接收到了ACK，就不會再發(fā)送斷開請求了，只需等待到服務(wù)器發(fā)送完數(shù)據(jù)，然后通過一個服務(wù)器發(fā)送到客戶端的斷開請求來確認(rèn)斷開就ok了，那么上面出現(xiàn)的情況就完美解決了

7 第三次握手失敗，應(yīng)該怎么處理

第三次握手失敗時的處理操作，可以看出當(dāng)失敗時服務(wù)器并不會重傳ack報文，而是直接發(fā)送RTS報文段，進(jìn)入CLOSED狀態(tài)。這樣做的目的是為了防止SYN洪泛攻擊。客戶端如果還想重新建立TCP鏈接，就必須重新開始第一次握手

8 關(guān)閉連接時，第四次握手失敗怎么處理

在關(guān)閉鏈接時，最后一個ACK丟失，實際上在第三步中，客戶端收到FIN包時，它會設(shè)置一個計時器，等待相當(dāng)長的一段時間，如果客戶端返回的ACK丟失，那么服務(wù)器還會重發(fā)FIN并充值計時器。假設(shè)在計時器失效前服務(wù)器重發(fā)的FIN包沒有到達(dá)客戶端，客戶端就會進(jìn)入CLOSE狀態(tài)，從而導(dǎo)致服務(wù)端永遠(yuǎn)無法收到ACK確認(rèn)，也就無法關(guān)閉鏈接。

9 TCP采用哪些方式保證傳輸可靠

1、應(yīng)用數(shù)據(jù)被分割成TCP認(rèn)為最適合發(fā)送的數(shù)據(jù)塊。
2、超時重傳：當(dāng)TCP發(fā)出一個段后，它啟動一個定時器，等待目的端確認(rèn)收到這個報文段。如果不能及時收到一個確認(rèn)，將重發(fā)這個報文段。
3、TCP給發(fā)送的每一個包進(jìn)行編號，接收方對數(shù)據(jù)包進(jìn)行排序，把有序數(shù)據(jù)傳送給應(yīng)用層。
4、校驗和：TCP將保持它首部和數(shù)據(jù)的檢驗和。這是一個端到端的檢驗和，目的是檢測數(shù)據(jù)在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP將丟棄這個報文段和不確認(rèn)收到此報文段。
5、TCP的接收端會丟棄重復(fù)的數(shù)據(jù)。
6、流量控制：TCP連接的每一方都有固定大小的緩沖空間，TCP的接收端只允許發(fā)送端發(fā)送接收端緩沖區(qū)能接納的我數(shù)據(jù)。當(dāng)接收方來不及處理發(fā)送方的數(shù)據(jù)，能提示發(fā)送方降低發(fā)送的速率，防止包丟失。TCP使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。
7、擁塞控制：當(dāng)網(wǎng)絡(luò)擁塞時，減少數(shù)據(jù)的發(fā)送

10 HTTP

HTTP是基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)的協(xié)議

請求.png

響應(yīng)ng

11 HTTP狀態(tài)碼

• 100 Continue 繼續(xù)，一般在發(fā)送post請求時，已發(fā)送了http header之后服務(wù)端將返回此信息，表示確認(rèn)，之后發(fā)送具體參數(shù)信息
• 200 OK 正常返回信息
• 201 Created 請求成功并且服務(wù)器創(chuàng)建了新的資源
• 202 Accepted 服務(wù)器已接受請求，但尚未處理
• 301 Moved Permanently 請求的網(wǎng)頁已永久移動到新位置。比如說我們在地址欄輸入baidu，雖然沒寫完整，但是瀏覽器會通過永久重定向去加上http://www.baidu.com,仍然會讓用戶訪問的到，服務(wù)器重定向會防止搜索引擎干預(yù)，搜索引擎收到301永久重定向就會把http://baidu.com和http://www.baidu.com看成一個網(wǎng)站；
• 302 Found 臨時性重定向。
• 303 See Other 臨時性重定向，且總是使用 GET 請求新的 URI。
• 304 Not Modified 自從上次請求后，請求的網(wǎng)頁未修改過。
• 400 Bad Request 服務(wù)器無法理解請求的格式，客戶端不應(yīng)當(dāng)嘗試再次使用相同的內(nèi)容發(fā)起請求。
• 401 Unauthorized 請求未授權(quán)。
• 403 Forbidden 禁止訪問。
• 404 Not Found 找不到如何與 URI 相匹配的資源。
• 500 Internal Server Error 最常見的服務(wù)器端錯誤。
• 503 Service Unavailable 服務(wù)器端暫時無法處理請求（可能是過載或維護(hù)）

12 HTTP 協(xié)議包括哪些請求

• GET：對服務(wù)器資源的簡單請求
• POST：用于發(fā)送包含用戶提交數(shù)據(jù)的請求
• HEAD：類似于GET請求，不過返回的響應(yīng)中沒有具體內(nèi)容，用于獲取報頭
• PUT：請求文檔的一個版本
• DELETE：發(fā)出一個刪除指定文檔的請求
• TRACE：發(fā)送一個請求副本，以跟蹤器處理進(jìn)程
• OPTIONS：返回所有可用的方法，檢查服務(wù)器支持哪些方法
• CONNECT：用于SSL隧道的基于代理的請求

13 HTTP請求GET和POST區(qū)別

• GET在瀏覽器回退時是無害的，而POST會再次提交請求。
• GET產(chǎn)生的URL地址可以被Bookmark，而POST不可以。
• GET請求會被瀏覽器主動cache，而POST不會，除非手動設(shè)置。
• GET請求只能進(jìn)行url編碼，而POST支持多種編碼方式。
• GET請求參數(shù)會被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會被保留。
• GET請求在URL中傳送的參數(shù)是有長度限制的，而POST沒有。
• 對參數(shù)的數(shù)據(jù)類型，GET只接受ASCII字符，而POST沒有限制。
• GET比POST更不安全，因為參數(shù)直接暴露在URL上，所以不能用來傳遞敏感信息。
• GET參數(shù)通過URL傳遞，POST放在Request body中
• GET產(chǎn)生一個TCP數(shù)據(jù)包；POST產(chǎn)生兩個TCP數(shù)據(jù)包。對于GET方式的請求，瀏覽器會把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200（返回數(shù)據(jù)）；而對于POST，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok（返回數(shù)據(jù)）

14 Cookie 和 Session的區(qū)別

1. cookie是存儲在客戶端
   cookie確切的說分為兩大類：會話cookie和持久化cookie。
   會話cookie是存放在客戶端瀏覽器的內(nèi)存中，他的生命周期和瀏覽器是一致的，當(dāng)瀏覽器關(guān)閉會話cookie也就消失了，
   持久化cookie是存放在客戶端硬盤中，持久化cookie的生命周期是我們在設(shè)置cookie時候設(shè)置的那個保存時間
2. 而session是存放在服務(wù)器的內(nèi)存中里，所以session里的數(shù)據(jù)不斷增加會造成服務(wù)器的負(fù)擔(dān)，所以會把很重要的信息存儲在session中，而把一些次要東西存儲在客戶端的cookie里。
   session的信息是通過sessionID獲取的，而sessionID是存放在會話cookie當(dāng)中的，當(dāng)瀏覽器關(guān)閉的時候會話cookie消失，所以sessionID也就消失了

15 HTTP請求的完整過程

DNS解析(通過訪問的域名找出其IP地址，遞歸搜索)
HTTP請求，當(dāng)輸入一個請求時，建立一個Socket連接發(fā)起TCP的3次握手
客戶端向服務(wù)器發(fā)送請求命令（一般是GET或POST請求）
客戶端發(fā)送請求頭信息
服務(wù)器發(fā)送應(yīng)答頭信息
服務(wù)器向客戶端發(fā)送數(shù)據(jù)
服務(wù)器關(guān)閉TCP連接（4次揮手）
客戶端根據(jù)返回的HTML，CSS，JS進(jìn)行渲染

16 HTTP和HTTPS

1、HTTP
HTTP協(xié)議建立在TCP連接之上，所有傳輸?shù)膬?nèi)容都是明文。
HTTP用的端口是80。
2、HTTPS
HTTPS建立在SSL/TLS之上，SSL/TLS建立在TCP連接之上，所有的傳輸內(nèi)容都是經(jīng)過加密的。
HTTPS用的端口是443。

參考文章

http://www.itdecent.cn/p/a1f5daf7ada5
http://www.cnblogs.com/BlueTzar/articles/811160.html
http://www.itdecent.cn/p/1c0eb9e67941
http://www.itdecent.cn/p/80a97488faa9
http://www.itdecent.cn/p/c2f0e2cb6180
https://blog.csdn.net/luobo140716/article/details/51880289
https://www.cnblogs.com/wrm1995/p/5627758.html
https://blog.csdn.net/q179886903/article/details/52741327
http://www.w3school.com.cn/tags/html_ref_httpmethods.asp