內(nèi)容參考-帥地玩編程

1、為什么需要三次握手？?jī)纱尾恍校?/h4>

• 三次握手
  當(dāng)面試官問(wèn)你為什么需要有三次握手、三次握手的作用、講講三次握手的時(shí)候，我想很多人會(huì)這樣回答：
  首先很多人會(huì)先講下握手的過(guò)程：
  1、第一次握手：客戶端給服務(wù)器發(fā)送一個(gè) SYN 報(bào)文。
  2、第二次握手：服務(wù)器收到 SYN 報(bào)文之后，會(huì)應(yīng)答一個(gè) SYN+ACK 報(bào)文。
  3、第三次握手：客戶端收到 SYN+ACK 報(bào)文之后，會(huì)回應(yīng)一個(gè) ACK 報(bào)文。
  4、服務(wù)器收到 ACK 報(bào)文之后，三次握手建立完成。
  作用是為了確認(rèn)雙方的接收與發(fā)送能力是否正常。
  這里我順便解釋一下為啥只有三次握手才能確認(rèn)雙方的接受與發(fā)送能力是否正常，而兩次卻不可以：
  第一次握手：客戶端發(fā)送網(wǎng)絡(luò)包，服務(wù)端收到了。這樣服務(wù)端就能得出結(jié)論：客戶端的發(fā)送能力、服務(wù)端的接收能力是正常的。
  第二次握手：服務(wù)端發(fā)包，客戶端收到了。這樣客戶端就能得出結(jié)論：服務(wù)端的接收、發(fā)送能力，客戶端的接收、發(fā)送能力是正常的。不過(guò)此時(shí)服務(wù)器并不能確認(rèn)客戶端的接收能力是否正常。
  第三次握手：客戶端發(fā)包，服務(wù)端收到了。這樣服務(wù)端就能得出結(jié)論：客戶端的接收、發(fā)送能力正常，服務(wù)器自己的發(fā)送、接收能力也正常。
  因此，需要三次握手才能確認(rèn)雙方的接收與發(fā)送能力是否正常。
  這樣回答其實(shí)也是可以的，但我覺(jué)得，這個(gè)過(guò)程的我們應(yīng)該要描述的更詳細(xì)一點(diǎn)，因?yàn)槿挝帐值倪^(guò)程中，雙方是由很多狀態(tài)的改變的，而這些狀態(tài)，也是面試官可能會(huì)問(wèn)的點(diǎn)。所以我覺(jué)得在回答三次握手的時(shí)候，我們應(yīng)該要描述的詳細(xì)一點(diǎn)，而且描述的詳細(xì)一點(diǎn)意味著可以扯久一點(diǎn)。加分的描述我覺(jué)得應(yīng)該是這樣：
  剛開(kāi)始客戶端處于 closed 的狀態(tài)，服務(wù)端處于 listen 狀態(tài)。然后
  1、第一次握手：客戶端給服務(wù)端發(fā)一個(gè) SYN 報(bào)文，并指明客戶端的初始化序列號(hào) ISN(c)。此時(shí)客戶端處于 SYN_Send 狀態(tài)。
  2、第二次握手：服務(wù)器收到客戶端的 SYN 報(bào)文之后，會(huì)以自己的 SYN 報(bào)文作為應(yīng)答，并且也是指定了自己的初始化序列號(hào) ISN(s)，同時(shí)會(huì)把客戶端的 ISN + 1 作為 ACK 的值，表示自己已經(jīng)收到了客戶端的 SYN，此時(shí)服務(wù)器處于 SYN_RCVD 的狀態(tài)。
  3、第三次握手：客戶端收到 SYN 報(bào)文之后，會(huì)發(fā)送一個(gè) ACK 報(bào)文，當(dāng)然，也是一樣把服務(wù)器的 ISN + 1 作為 ACK 的值，表示已經(jīng)收到了服務(wù)端的 SYN 報(bào)文，此時(shí)客戶端處于 established 狀態(tài)。
  4、服務(wù)器收到 ACK 報(bào)文之后，也處于 established 狀態(tài)，此時(shí)，雙方建立起了鏈接

• 三次握手的作用
  三次握手的作用也是有好多的，多記住幾個(gè)，保證不虧。例如：
  1、確認(rèn)雙方的接受能力、發(fā)送能力是否正常。
  2、指定自己的初始化序列號(hào)，為后面的可靠傳送做準(zhǔn)備。
  1、（ISN）是固定的嗎
  三次握手的一個(gè)重要功能是客戶端和服務(wù)端交換ISN(Initial Sequence Number), 以便讓對(duì)方知道接下來(lái)接收數(shù)據(jù)的時(shí)候如何按序列號(hào)組裝數(shù)據(jù)。
  如果ISN是固定的，攻擊者很容易猜出后續(xù)的確認(rèn)號(hào)，因此 ISN 是動(dòng)態(tài)生成的。
  2、什么是半連接隊(duì)列
  服務(wù)器第一次收到客戶端的 SYN 之后，就會(huì)處于 SYN_RCVD 狀態(tài)，此時(shí)雙方還沒(méi)有完全建立其連接，服務(wù)器會(huì)把此種狀態(tài)下請(qǐng)求連接放在一個(gè)隊(duì)列里，我們把這種隊(duì)列稱之為半連接隊(duì)列。當(dāng)然還有一個(gè)全連接隊(duì)列，就是已經(jīng)完成三次握手，建立起連接的就會(huì)放在全連接隊(duì)列中。如果隊(duì)列滿了就有可能會(huì)出現(xiàn)丟包現(xiàn)象。
  這里在補(bǔ)充一點(diǎn)關(guān)于SYN-ACK 重傳次數(shù)的問(wèn)題：　服務(wù)器發(fā)送完SYN－ACK包，如果未收到客戶確認(rèn)包，服務(wù)器進(jìn)行首次重傳，等待一段時(shí)間仍未收到客戶確認(rèn)包，進(jìn)行第二次重傳，如果重傳次數(shù)超 過(guò)系統(tǒng)規(guī)定的最大重傳次數(shù)，系統(tǒng)將該連接信息從半連接隊(duì)列中刪除。注意，每次重傳等待的時(shí)間不一定相同，一般會(huì)是指數(shù)增長(zhǎng)，例如間隔時(shí)間為 1s, 2s, 4s, 8s,
  3、三次握手過(guò)程中可以攜帶數(shù)據(jù)嗎
  很多人可能會(huì)認(rèn)為三次握手都不能攜帶數(shù)據(jù)，其實(shí)第三次握手的時(shí)候，是可以攜帶數(shù)據(jù)的。也就是說(shuō)，第一次、第二次握手不可以攜帶數(shù)據(jù)，而第三次握手是可以攜帶數(shù)據(jù)的。
  為什么這樣呢？大家可以想一個(gè)問(wèn)題，假如第一次握手可以攜帶數(shù)據(jù)的話，如果有人要惡意攻擊服務(wù)器，那他每次都在第一次握手中的 SYN 報(bào)文中放入大量的數(shù)據(jù)，因?yàn)楣粽吒揪筒焕矸?wù)器的接收、發(fā)送能力是否正常，然后瘋狂著重復(fù)發(fā) SYN 報(bào)文的話，這會(huì)讓服務(wù)器花費(fèi)很多時(shí)間、內(nèi)存空間來(lái)接收這些報(bào)文。也就是說(shuō)，第一次握手可以放數(shù)據(jù)的話，其中一個(gè)簡(jiǎn)單的原因就是會(huì)讓服務(wù)器更加容易受到攻擊了。
  而對(duì)于第三次的話，此時(shí)客戶端已經(jīng)處于 established 狀態(tài)，也就是說(shuō)，對(duì)于客戶端來(lái)說(shuō)，他已經(jīng)建立起連接了，并且也已經(jīng)知道服務(wù)器的接收、發(fā)送能力是正常的了，所以能攜帶數(shù)據(jù)頁(yè)沒(méi)啥毛病。

2、為什么需要四次揮手？三次不行？

四次揮手也一樣，千萬(wàn)不要對(duì)方一個(gè) FIN 報(bào)文，我方一個(gè) ACK 報(bào)文，再我方一個(gè) FIN 報(bào)文，我方一個(gè) ACK 報(bào)文。然后結(jié)束，最好是說(shuō)的詳細(xì)一點(diǎn)，例如想下面這樣就差不多了，要把每個(gè)階段的狀態(tài)記好，我上次面試就被問(wèn)了幾個(gè)了，呵呵。我答錯(cuò)了，還以為自己答對(duì)了，當(dāng)時(shí)還解釋的頭頭是道，呵呵。
剛開(kāi)始雙方都處于 establised 狀態(tài)，假如是客戶端先發(fā)起關(guān)閉請(qǐng)求，則：
1、第一次揮手：客戶端發(fā)送一個(gè) FIN 報(bào)文，報(bào)文中會(huì)指定一個(gè)序列號(hào)。此時(shí)客戶端處于FIN_WAIT1狀態(tài)。
2、第二次握手：服務(wù)端收到 FIN 之后，會(huì)發(fā)送 ACK 報(bào)文，且把客戶端的序列號(hào)值 + 1 作為 ACK 報(bào)文的序列號(hào)值，表明已經(jīng)收到客戶端的報(bào)文了，此時(shí)服務(wù)端處于 CLOSE_WAIT2狀態(tài)。
3、第三次揮手：如果服務(wù)端也想斷開(kāi)連接了，和客戶端的第一次揮手一樣，發(fā)給 FIN 報(bào)文，且指定一個(gè)序列號(hào)。此時(shí)服務(wù)端處于 LAST_ACK 的狀態(tài)。
4、第四次揮手：客戶端收到 FIN 之后，一樣發(fā)送一個(gè) ACK 報(bào)文作為應(yīng)答，且把服務(wù)端的序列號(hào)值 + 1 作為自己 ACK 報(bào)文的序列號(hào)值，此時(shí)客戶端處于 TIME_WAIT 狀態(tài)。需要過(guò)一陣子以確保服務(wù)端收到自己的 ACK 報(bào)文之后才會(huì)進(jìn)入 CLOSED 狀態(tài)
5、服務(wù)端收到 ACK 報(bào)文之后，就處于關(guān)閉連接了，處于 CLOSED 狀態(tài)。

這里特別需要主要的就是TIME_WAIT這個(gè)狀態(tài)了，這個(gè)是面試的高頻考點(diǎn)，就是要理解，為什么客戶端發(fā)送 ACK 之后不直接關(guān)閉，而是要等一陣子才關(guān)閉。這其中的原因就是，要確保服務(wù)器是否已經(jīng)收到了我們的 ACK 報(bào)文，如果沒(méi)有收到的話，服務(wù)器會(huì)重新發(fā) FIN 報(bào)文給客戶端，客戶端再次收到 FIN 報(bào)文之后，就知道之前的 ACK 報(bào)文丟失了，然后再次發(fā)送 ACK 報(bào)文。
至于 TIME_WAIT 持續(xù)的時(shí)間至少是一個(gè)報(bào)文的來(lái)回時(shí)間。一般會(huì)設(shè)置一個(gè)計(jì)時(shí)，如果過(guò)了這個(gè)計(jì)時(shí)沒(méi)有再次收到 FIN 報(bào)文，則代表對(duì)方成功就是 ACK 報(bào)文，此時(shí)處于 CLOSED 狀態(tài)。
這里我給出每個(gè)狀態(tài)所包含的含義，有興趣的可以看看。
LISTEN – 偵聽(tīng)來(lái)自遠(yuǎn)方TCP端口的連接請(qǐng)求；
SYN-SENT -在發(fā)送連接請(qǐng)求后等待匹配的連接請(qǐng)求；
SYN-RECEIVED – 在收到和發(fā)送一個(gè)連接請(qǐng)求后等待對(duì)連接請(qǐng)求的確認(rèn)；

ESTABLISHED- 代表一個(gè)打開(kāi)的連接，數(shù)據(jù)可以傳送給用戶；
FIN-WAIT-1 – 等待遠(yuǎn)程TCP的連接中斷請(qǐng)求，或先前的連接中斷請(qǐng)求的確認(rèn)；
FIN-WAIT-2 – 從遠(yuǎn)程TCP等待連接中斷請(qǐng)求；
CLOSE-WAIT – 等待從本地用戶發(fā)來(lái)的連接中斷請(qǐng)求；
CLOSING -等待遠(yuǎn)程TCP對(duì)連接中斷的確認(rèn)；
LAST-ACK – 等待原來(lái)發(fā)向遠(yuǎn)程TCP的連接中斷請(qǐng)求的確認(rèn)；
TIME-WAIT -等待足夠的時(shí)間以確保遠(yuǎn)程TCP接收到連接中斷請(qǐng)求的確認(rèn)；
CLOSED – 沒(méi)有任何連接狀態(tài)；

3、TCP與UDP有哪些區(qū)別？各自應(yīng)用場(chǎng)景？

• TCP協(xié)議的主要特點(diǎn)
  （1）TCP是面向連接的運(yùn)輸層協(xié)議；所謂面向連接就是雙方傳輸數(shù)據(jù)之前，必須先建立一條通道，例如三次握手就是建議通道的一個(gè)過(guò)程，而四次揮手則是結(jié)束銷(xiāo)毀通道的一個(gè)其中過(guò)程。
  （2）每一條TCP連接只能有兩個(gè)端點(diǎn)（即兩個(gè)套接字），只能是點(diǎn)對(duì)點(diǎn)的；
  （3）TCP提供可靠的傳輸服務(wù)。傳送的數(shù)據(jù)無(wú)差錯(cuò)、不丟失、不重復(fù)、按序到達(dá)；
  （4）TCP提供全雙工通信。允許通信雙方的應(yīng)用進(jìn)程在任何時(shí)候都可以發(fā)送數(shù)據(jù)，因?yàn)閮啥硕荚O(shè)有發(fā)送緩存和接受緩存；
  （5）面向字節(jié)流。雖然應(yīng)用程序與TCP交互是一次一個(gè)大小不等的數(shù)據(jù)塊，但TCP把這些數(shù)據(jù)看成一連串無(wú)結(jié)構(gòu)的字節(jié)流，它不保證接收方收到的數(shù)據(jù)塊和發(fā)送方發(fā)送的數(shù)據(jù)塊具有對(duì)應(yīng)大小關(guān)系，例如，發(fā)送方應(yīng)用程序交給發(fā)送方的TCP10個(gè)數(shù)據(jù)塊，但就受訪的TCP可能只用了4個(gè)數(shù)據(jù)塊久保收到的字節(jié)流交付給上層的應(yīng)用程序，但字節(jié)流完全一樣。
• TCP的可靠性原理
  可靠傳輸有如下兩個(gè)特點(diǎn):
  a.傳輸信道無(wú)差錯(cuò),保證傳輸數(shù)據(jù)正確;
  b.不管發(fā)送方以多快的速度發(fā)送數(shù)據(jù),接收方總是來(lái)得及處理收到的數(shù)據(jù);
  （1）首先，采用三次握手來(lái)建立TCP連接，四次握手來(lái)釋放TCP連接，從而保證建立的傳輸信道是可靠的。
  （2）其次，TCP采用了連續(xù)ARQ協(xié)議（回退N，Go-back-N；超時(shí)自動(dòng)重傳）來(lái)保證數(shù)據(jù)傳輸?shù)恼_性，使用滑動(dòng)窗口協(xié)議來(lái)保證接方能夠及時(shí)處理所接收到的數(shù)據(jù)，進(jìn)行流量控制。
  （3）最后，TCP使用慢開(kāi)始、擁塞避免、快重傳和快恢復(fù)來(lái)進(jìn)行擁塞控制，避免網(wǎng)絡(luò)擁塞。
• UDP協(xié)議特點(diǎn)
  （１）UDP是無(wú)連接的傳輸層協(xié)議；
  （２）UDP使用盡最大努力交付，不保證可靠交付；
  （３）UDP是面向報(bào)文的，對(duì)應(yīng)用層交下來(lái)的報(bào)文，不合并，不拆分，保留原報(bào)文的邊界；
  （４）UDP沒(méi)有擁塞控制，因此即使網(wǎng)絡(luò)出現(xiàn)擁塞也不會(huì)降低發(fā)送速率；
  （５）UDP支持一對(duì)一　一對(duì)多　多對(duì)多的交互通信；
  （６）UDP的首部開(kāi)銷(xiāo)小，只有８字節(jié)．
• TCP和UDP的區(qū)別
  (1)TCP是可靠傳輸,UDP是不可靠傳輸;
  (2)TCP面向連接,UDP無(wú)連接;
  (3)TCP傳輸數(shù)據(jù)有序,UDP不保證數(shù)據(jù)的有序性;
  (4)TCP不保存數(shù)據(jù)邊界,UDP保留數(shù)據(jù)邊界;
  (5)TCP傳輸速度相對(duì)UDP較慢;
  (6)TCP有流量控制和擁塞控制,UDP沒(méi)有;
  (７)TCP是重量級(jí)協(xié)議,UDP是輕量級(jí)協(xié)議;
  (８)TCP首部較長(zhǎng)２０字節(jié),UDP首部較短８字節(jié);
• 基于TCP和UDP的常用協(xié)議
  HTTP、HTTPS、FTP、TELNET、SMTP(簡(jiǎn)單郵件傳輸協(xié)議)協(xié)議基于可靠的TCP協(xié)議。TFTP、DNS、DHCP、TFTP、SNMP(簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議)、RIP基于不可靠的UDP協(xié)議
  TCP 和 UDP 的常用場(chǎng)景，這個(gè)問(wèn)的好挺多的，例如我當(dāng)時(shí)面試時(shí)，就被問(wèn)過(guò)：QQ 登錄的過(guò)程中，用到了 TCP 和 UDP，QQ 通話呢？

4、HTTP1.0，1.1，2.0 的版本區(qū)別

• HTTP/1.0
  1996年5月，HTTP/1.0 版本發(fā)布，為了提高系統(tǒng)的效率，HTTP/1.0規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接，服務(wù)器完成請(qǐng)求處理后立即斷開(kāi)TCP連接，服務(wù)器不跟蹤每個(gè)客戶也不記錄過(guò)去的請(qǐng)求。
  這種方式就好像我們打電話的時(shí)候，只能說(shuō)一件事兒一樣，說(shuō)完之后就要掛斷，想要說(shuō)另外一件事兒的時(shí)候就要重新?lián)艽螂娫挕?br> HTTP/1.0中瀏覽器與服務(wù)器只保持短暫的連接，連接無(wú)法復(fù)用。也就是說(shuō)每個(gè)TCP連接只能發(fā)送一個(gè)請(qǐng)求。發(fā)送數(shù)據(jù)完畢，連接就關(guān)閉，如果還要請(qǐng)求其他資源，就必須再新建一個(gè)連接。
  我們知道TCP連接的建立需要三次握手，是很耗費(fèi)時(shí)間的一個(gè)過(guò)程。所以，HTTP/1.0版本的性能比較差。
  HTTP1.0 其實(shí)也可以強(qiáng)制開(kāi)啟長(zhǎng)鏈接，例如接受Connection: keep-alive 這個(gè)字段，但是，這不是標(biāo)準(zhǔn)字段，不同實(shí)現(xiàn)的行為可能不一致，因此不是根本的解決辦法。
• HTTP/1.1
  為了解決HTTP/1.0存在的缺陷，HTTP/1.1于1999年誕生。相比較于HTTP/1.0來(lái)說(shuō)，最主要的改進(jìn)就是引入了持久連接。所謂的持久連接即TCP連接默認(rèn)不關(guān)閉，可以被多個(gè)請(qǐng)求復(fù)用。
  由于之前打一次電話只能說(shuō)一件事兒，效率很低。后來(lái)人們提出一種想法，就是電話打完之后，先不直接掛斷，而是持續(xù)一小段時(shí)間，這一小段時(shí)間內(nèi)，如果還有事情溝通可以再次進(jìn)行溝通。
  客戶端和服務(wù)器發(fā)現(xiàn)對(duì)方一段時(shí)間沒(méi)有活動(dòng)，就可以主動(dòng)關(guān)閉連接?；蛘呖蛻舳嗽谧詈笠粋€(gè)請(qǐng)求時(shí)，主動(dòng)告訴服務(wù)端要關(guān)閉連接。
  HTTP/1.1版還引入了管道機(jī)制（pipelining），即在同一個(gè)TCP連接里面，客戶端可以同時(shí)發(fā)送多個(gè)請(qǐng)求。這樣就進(jìn)一步改進(jìn)了HTTP協(xié)議的效率。

有了持久連接和管道，大大的提升了HTTP的效率。但是服務(wù)端還是順序執(zhí)行的，效率還有提升的空間。

• HTTP/2
  HTTP/2 是 HTTP 協(xié)議自 1999 年 HTTP 1.1 發(fā)布后的首個(gè)更新，主要基于 SPDY 協(xié)議。
  HTTP/2 為了解決HTTP/1.1中仍然存在的效率問(wèn)題，HTTP/2 采用了多路復(fù)用。即在一個(gè)連接里，客戶端和瀏覽器都可以同時(shí)發(fā)送多個(gè)請(qǐng)求或回應(yīng)，而且不用按照順序一一對(duì)應(yīng)。能這樣做有一個(gè)前提，就是HTTP/2進(jìn)行了二進(jìn)制分幀，即 HTTP/2 會(huì)將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶╢rame）,并對(duì)它們采用二進(jìn)制格式的編碼。
  也就是說(shuō)，老板可以同時(shí)下達(dá)多個(gè)命令，員工也可以收到了A請(qǐng)求和B請(qǐng)求，于是先回應(yīng)A請(qǐng)求，結(jié)果發(fā)現(xiàn)處理過(guò)程非常耗時(shí)，于是就發(fā)送A請(qǐng)求已經(jīng)處理好的部分， 接著回應(yīng)B請(qǐng)求，完成后，再發(fā)送A請(qǐng)求剩下的部分。A請(qǐng)求的兩部分響應(yīng)在組合到一起發(fā)給老板。

而這個(gè)負(fù)責(zé)拆分、組裝請(qǐng)求和二進(jìn)制幀的一層就叫做二進(jìn)制分幀層。
除此之外，還有一些其他的優(yōu)化，比如做Header壓縮、服務(wù)端推送等。
Header壓縮就是壓縮老板和員工之間的對(duì)話。
服務(wù)端推送就是員工事先把一些老板可能詢問(wèn)的事情提現(xiàn)發(fā)送到老板的手機(jī)（緩存）上。這樣老板想要知道的時(shí)候就可以直接讀取短信（緩存）了。
目前，主流的HTTP協(xié)議還是HTTP/1.1 和 HTTP/2。并且各大網(wǎng)站的HTTP/2的使用率也在逐年增加。

5、POST和GET有哪些區(qū)別？各自應(yīng)用場(chǎng)景？

• 使用場(chǎng)景
  GET 用于獲取資源，而 POST 用于傳輸實(shí)體主體。
• 參數(shù)
  GET 和 POST 的請(qǐng)求都能使用額外的參數(shù)，但是 GET 的參數(shù)是以查詢字符串出現(xiàn)在 URL 中，而 POST 的參數(shù)存儲(chǔ)在實(shí)體主體中。不能因?yàn)?POST 參數(shù)存儲(chǔ)在實(shí)體主體中就認(rèn)為它的安全性更高，因?yàn)檎諛涌梢酝ㄟ^(guò)一些抓包工具（Fiddler）查看。
  因?yàn)?URL 只支持 ASCII 碼，因此 GET 的參數(shù)中如果存在中文等字符就需要先進(jìn)行編碼。例如 中文 會(huì)轉(zhuǎn)換為 %E4%B8%AD%E6%96%87，而空格會(huì)轉(zhuǎn)換為 %20。POST 參數(shù)支持標(biāo)準(zhǔn)字符集。

GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1Copy to clipboardErrorCopied
POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2Copy to clipboardErrorCopied

• 安全性
  安全的 HTTP 方法不會(huì)改變服務(wù)器狀態(tài)，也就是說(shuō)它只是可讀的。
  GET 方法是安全的，而 POST 卻不是，因?yàn)?POST 的目的是傳送實(shí)體主體內(nèi)容，這個(gè)內(nèi)容可能是用戶上傳的表單數(shù)據(jù)，上傳成功之后，服務(wù)器可能把這個(gè)數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)中，因此狀態(tài)也就發(fā)生了改變。
  安全的方法除了 GET 之外還有：HEAD、OPTIONS。
  不安全的方法除了 POST 之外還有 PUT、DELETE。
• 冪等性
  冪等的 HTTP 方法，同樣的請(qǐng)求被執(zhí)行一次與連續(xù)執(zhí)行多次的效果是一樣的，服務(wù)器的狀態(tài)也是一樣的。換句話說(shuō)就是，冪等方法不應(yīng)該具有副作用（統(tǒng)計(jì)用途除外）。
  所有的安全方法也都是冪等的。
  在正確實(shí)現(xiàn)的條件下，GET，HEAD，PUT 和 DELETE 等方法都是冪等的，而 POST 方法不是。
  GET /pageX HTTP/1.1 是冪等的，連續(xù)調(diào)用多次，客戶端接收到的結(jié)果都是一樣的：

GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1Copy to clipboardErrorCopied

POST /add_row HTTP/1.1 不是冪等的，如果調(diào)用多次，就會(huì)增加多行記錄：

POST /add_row HTTP/1.1   -> Adds a 1nd row
POST /add_row HTTP/1.1   -> Adds a 2nd row
POST /add_row HTTP/1.1   -> Adds a 3rd rowCopy to clipboardErrorCopied

DELETE /idX/delete HTTP/1.1 是冪等的，即使不同的請(qǐng)求接收到的狀態(tài)碼不一樣：

DELETE /idX/delete HTTP/1.1   -> Returns 200 if idX exists
DELETE /idX/delete HTTP/1.1   -> Returns 404 as it just got deleted
DELETE /idX/delete HTTP/1.1   -> Returns 404Copy to clipboardErrorCopied

• 緩存
  如果要對(duì)響應(yīng)進(jìn)行緩存，需要滿足以下條件：
  請(qǐng)求報(bào)文的 HTTP 方法本身是可緩存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可緩存，POST 在多數(shù)情況下不可緩存的。
  響應(yīng)報(bào)文的狀態(tài)碼是可緩存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
  響應(yīng)報(bào)文的 Cache-Control 首部字段沒(méi)有指定不進(jìn)行緩存。
• XMLHttpRequest
  為了闡述 POST 和 GET 的另一個(gè)區(qū)別，需要先了解 XMLHttpRequest：
  XMLHttpRequest 是一個(gè) API，它為客戶端提供了在客戶端和服務(wù)器之間傳輸數(shù)據(jù)的功能。它提供了一個(gè)通過(guò) URL 來(lái)獲取數(shù)據(jù)的簡(jiǎn)單方式，并且不會(huì)使整個(gè)頁(yè)面刷新。這使得網(wǎng)頁(yè)只更新一部分頁(yè)面而不會(huì)打擾到用戶。XMLHttpRequest 在 AJAX 中被大量使用。
  在使用 XMLHttpRequest 的 POST 方法時(shí)，瀏覽器會(huì)先發(fā)送 Header 再發(fā)送 Data。但并不是所有瀏覽器會(huì)這么做，例如火狐就不會(huì)。
  而 GET 方法 Header 和 Data 會(huì)一起發(fā)送。

6、HTTP 哪些常用的狀態(tài)碼及使用場(chǎng)景？

• 狀態(tài)碼分類
  1xx：表示目前是協(xié)議的中間狀態(tài)，還需要后續(xù)請(qǐng)求
  2xx：表示請(qǐng)求成功
  3xx：表示重定向狀態(tài)，需要重新請(qǐng)求
  4xx：表示請(qǐng)求報(bào)文錯(cuò)誤
  5xx：服務(wù)器端錯(cuò)誤
• 常用狀態(tài)碼
  101 切換請(qǐng)求協(xié)議，從 HTTP 切換到 WebSocket
  200 請(qǐng)求成功，有響應(yīng)體
  301 永久重定向：會(huì)緩存
  302 臨時(shí)重定向：不會(huì)緩存
  304 協(xié)商緩存命中
  403 服務(wù)器禁止訪問(wèn)
  404 資源未找到
  400 請(qǐng)求錯(cuò)誤
  500 服務(wù)器端錯(cuò)誤
  503 服務(wù)器繁忙

7、HTTP狀態(tài)碼301和302的區(qū)別，都有哪些用途？

• 301重定向的概念
  301重定向（301 Move Permanently），指頁(yè)面永久性轉(zhuǎn)移，表示為資源或頁(yè)面永久性地轉(zhuǎn)移到了另一個(gè)位置。301是HTTP協(xié)議中的一種狀態(tài)碼，當(dāng)用戶或搜索引擎向服務(wù)器發(fā)出瀏覽請(qǐng)求時(shí)，服務(wù)器返回的HTTP數(shù)據(jù)流中頭信息（header）中包含狀態(tài)碼 301 ，表示該資源已經(jīng)永久改變了位置。
  301重定向是一種非常重要的”自動(dòng)轉(zhuǎn)向“技術(shù)，網(wǎng)址重定向最為可行的一種方法。
• 哪些情況需要做301重定向？
  網(wǎng)頁(yè)開(kāi)發(fā)過(guò)程中，時(shí)常會(huì)遇到網(wǎng)站目錄結(jié)構(gòu)的調(diào)整，將頁(yè)面轉(zhuǎn)移到一個(gè)新地址；網(wǎng)頁(yè)擴(kuò)展名的改變，這些變化都會(huì)導(dǎo)致網(wǎng)頁(yè)地址發(fā)生改變，此時(shí)用戶收藏夾和搜索引擎數(shù)據(jù)庫(kù)中的舊地址是一個(gè)錯(cuò)誤的地址，訪問(wèn)之后會(huì)出現(xiàn)404頁(yè)面，直接導(dǎo)致網(wǎng)站流量的損失。或者是我們需要多個(gè)域名跳轉(zhuǎn)至同一個(gè)域名，例如本站主站點(diǎn)域名為 www.conimi.com ，而還有一個(gè)域名 www.nico.cc，由于對(duì)該域名設(shè)置了301重定向，當(dāng)輸入www.nico.cc 時(shí)，自動(dòng)跳轉(zhuǎn)至 www.conimi.com 。
• 301重定向有什么優(yōu)點(diǎn)？
  有利于網(wǎng)站首選域的確定，對(duì)于同一資源頁(yè)面多條路徑的301重定向有助于URL權(quán)重的集中。例如 www.conimi.com和 conimi.com 是兩個(gè)不同的域名，但是指向的內(nèi)容完全相同，搜索引擎會(huì)對(duì)兩個(gè)域名收錄情況不同，這樣導(dǎo)致網(wǎng)站權(quán)重和排名被分散；對(duì)conimi.com 做301重定向跳轉(zhuǎn)至www.conimi.com 后，權(quán)重和排名集中到www.conimi.com，從而提升自然排名。
• 302重定向又是什么鬼？
  302重定向（302 Move Temporarily），指頁(yè)面暫時(shí)性轉(zhuǎn)移，表示資源或頁(yè)面暫時(shí)轉(zhuǎn)移到另一個(gè)位置，常被用作網(wǎng)址劫持，容易導(dǎo)致網(wǎng)站降權(quán)，嚴(yán)重時(shí)網(wǎng)站會(huì)被封掉，不推薦使用。
• 301與302的區(qū)別
  302重定向是頁(yè)面暫時(shí)性轉(zhuǎn)移，搜索引擎會(huì)抓取新的內(nèi)容而保存舊的網(wǎng)址并認(rèn)為新的網(wǎng)址只是暫時(shí)的。

8、在交互過(guò)程中如果數(shù)據(jù)傳送完了，還不想斷開(kāi)連接怎么辦，怎么維持？

在 HTTP 中響應(yīng)體的 Connection 字段指定為 keep-alive
connetion:keep-alive;

9、HTTP 如何實(shí)現(xiàn)長(zhǎng)連接？在什么時(shí)候會(huì)超時(shí)？

通過(guò)在頭部（請(qǐng)求和響應(yīng)頭）設(shè)置 Connection: keep-alive，HTTP1.0協(xié)議支持，但是默認(rèn)關(guān)閉，從HTTP1.1協(xié)議以后，連接默認(rèn)都是長(zhǎng)連接
1、HTTP 一般會(huì)有 httpd 守護(hù)進(jìn)程，里面可以設(shè)置 keep-alive timeout，當(dāng) tcp 鏈接閑置超過(guò)這個(gè)時(shí)間就會(huì)關(guān)閉，也可以在 HTTP 的 header 里面設(shè)置超時(shí)時(shí)間
2、TCP 的 keep-alive 包含三個(gè)參數(shù)，支持在系統(tǒng)內(nèi)核的 net.ipv4 里面設(shè)置：當(dāng) TCP 鏈接之后，閑置了 tcp_keepalive_time，則會(huì)發(fā)生偵測(cè)包，如果沒(méi)有收到對(duì)方的 ACK，那么會(huì)每隔 tcp_keepalive_intvl 再發(fā)一次，直到發(fā)送了 tcp_keepalive_probes，就會(huì)丟棄該鏈接。
（1）tcp_keepalive_intvl = 15
（2）tcp_keepalive_probes = 5
（3）tcp_keepalive_time = 1800
實(shí)際上 HTTP 沒(méi)有長(zhǎng)短鏈接，只有 TCP 有，TCP 長(zhǎng)連接可以復(fù)用一個(gè) TCP 鏈接來(lái)發(fā)起多次 HTTP 請(qǐng)求，這樣可以減少資源消耗，比如一次請(qǐng)求 HTML，可能還需要請(qǐng)求后續(xù)的 JS/CSS/圖片等

10、TCP 如何保證有效傳輸及擁塞控制原理

tcp 是面向連接的、可靠的、傳輸層通信協(xié)議

• 可靠體現(xiàn)在：有狀態(tài)、可控制
  有狀態(tài)是指 TCP 會(huì)確認(rèn)發(fā)送了哪些報(bào)文，接收方受到了哪些報(bào)文，哪些沒(méi)有收到，保證數(shù)據(jù)包按序到達(dá)，不允許有差錯(cuò)
  可控制的是指，如果出現(xiàn)丟包或者網(wǎng)絡(luò)狀況不佳，則會(huì)跳轉(zhuǎn)自己的行為，減少發(fā)送的速度或者重發(fā)
  所以上面能保證數(shù)據(jù)包的有效傳輸。
• 擁塞控制原理
  原因是有可能整個(gè)網(wǎng)絡(luò)環(huán)境特別差，容易丟包，那么發(fā)送端就應(yīng)該注意了。
  主要用三種方法：慢啟動(dòng)閾值 + 擁塞避免；快速重傳；快速回復(fù)
• 慢啟動(dòng)閾值 + 擁塞避免：
  對(duì)于擁塞控制來(lái)說(shuō)，TCP 主要維護(hù)兩個(gè)核心狀態(tài)：擁塞窗口（cwnd）、慢啟動(dòng)閾值（ssthresh）
  在發(fā)送端使用擁塞窗口來(lái)控制發(fā)送窗口的大?。蝗缓蟛捎靡环N比較保守的慢啟動(dòng)算法來(lái)慢慢適應(yīng)這個(gè)網(wǎng)絡(luò)，在開(kāi)始傳輸?shù)囊欢螘r(shí)間，發(fā)送端和接收端會(huì)首先通過(guò)三次握手建立連接，確定各自接收窗口大小，然后初始化雙方的擁塞窗口，接著每經(jīng)過(guò)一輪 RTT（收發(fā)時(shí)延），擁塞窗口大小翻倍，直到達(dá)到慢啟動(dòng)閾值。
  然后開(kāi)始進(jìn)行擁塞避免，擁塞避免具體的做法就是之前每一輪 RTT，擁塞窗口翻倍，現(xiàn)在每一輪就加一個(gè)。
• 快速重傳：
  在 TCP 傳輸過(guò)程中，如果發(fā)生了丟包，接收端就會(huì)發(fā)送之前重復(fù) ACK，比如 第 5 個(gè)包丟了，6、7 達(dá)到，然后接收端會(huì)為 5，6，7 都發(fā)送第四個(gè)包的 ACK，這個(gè)時(shí)候發(fā)送端受到了 3 個(gè)重復(fù)的 ACK，意識(shí)到丟包了，就會(huì)馬上進(jìn)行重傳，而不用等到 RTO （超時(shí)重傳的時(shí)間）
  選擇性重傳：報(bào)文首部可選性中加入 SACK 屬性，通過(guò) left edge 和 right edge 標(biāo)志那些包到了，然后重傳沒(méi)到的包
• 快速回復(fù)：
  如果發(fā)送端收到了 3 個(gè)重復(fù)的 ACK，發(fā)現(xiàn)了丟包，覺(jué)得現(xiàn)在的網(wǎng)絡(luò)狀況已經(jīng)進(jìn)入擁塞狀態(tài)了，那么就會(huì)進(jìn)入快速恢復(fù)階段：
  會(huì)將擁塞閾值降低為 擁塞窗口的一半
  然后擁塞窗口大小變?yōu)閾砣撝?br> 接著 擁塞窗口再進(jìn)行線性增加，以適應(yīng)網(wǎng)絡(luò)狀況

11、IP地址有哪些分類？

A類地址(1~126)：網(wǎng)絡(luò)號(hào)占前8位，以0開(kāi)頭，主機(jī)號(hào)占后24位。
B類地址(128~191)：網(wǎng)絡(luò)號(hào)占前16位，以10開(kāi)頭，主機(jī)號(hào)占后16位。
C類地址(192~223)：網(wǎng)絡(luò)號(hào)占前24位，以110開(kāi)頭，主機(jī)號(hào)占后8位。
D類地址(224~239)：以1110開(kāi)頭，保留位多播地址。
E類地址(240~255)：以1111開(kāi)頭，保留位今后使用

12、GET請(qǐng)求中URL編碼的意義

我們知道，在GET請(qǐng)求中會(huì)對(duì)URL中非西文字符進(jìn)行編碼，這樣做的目的就是為了避免歧義。看下面的例子，
針對(duì)“name1=value1&name2=value2”的例子，我們來(lái)談一下數(shù)據(jù)從客戶端到服務(wù)端的解析過(guò)程。首先，上述字符串在計(jì)算機(jī)中用ASCII碼表示為：

   6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532
   6E616D6531：name1 
   3D：= 
   76616C756531：value1 
   26：&
   6E616D6532：name2 
   3D：= 
   76616C756532：value2

服務(wù)端在接收到該數(shù)據(jù)后就可以遍歷該字節(jié)流，一個(gè)字節(jié)一個(gè)字節(jié)的吃，當(dāng)吃到3D這字節(jié)后，服務(wù)端就知道前面吃得字節(jié)表示一個(gè)key，再往后吃，如果遇到26，說(shuō)明從剛才吃的3D到26子節(jié)之間的是上一個(gè)key的value，以此類推就可以解析出客戶端傳過(guò)來(lái)的參數(shù)。
現(xiàn)在考慮這樣一個(gè)問(wèn)題，如果我們的參數(shù)值中就包含 = 或 & 這種特殊字符的時(shí)候該怎么辦？比如，“name1=value1”，其中value1的值是“va&lu=e1”字符串，那么實(shí)際在傳輸過(guò)程中就會(huì)變成這樣“name1=va&lu=e1”。這樣，我們的本意是只有一個(gè)鍵值對(duì)，但是服務(wù)端卻會(huì)解析成兩個(gè)鍵值對(duì)，這樣就產(chǎn)生了歧義。
那么，如何解決上述問(wèn)題帶來(lái)的歧義呢？解決的辦法就是對(duì)參數(shù)進(jìn)行URL編碼：例如，我們對(duì)上述會(huì)產(chǎn)生歧義的字符進(jìn)行URL編碼后結(jié)果：“name1=va%26lu%3D”，這樣服務(wù)端會(huì)把緊跟在“%”后的字節(jié)當(dāng)成普通的字節(jié)，就是不會(huì)把它當(dāng)成各個(gè)參數(shù)或鍵值對(duì)的分隔符

13、什么是SQL 注入？舉個(gè)例子？

SQL注入就是通過(guò)把SQL命令插入到Web表單提交或輸入域名或頁(yè)面請(qǐng)求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。

• SQL注入攻擊的總體思路
  (1). 尋找到SQL注入的位置
  (2). 判斷服務(wù)器類型和后臺(tái)數(shù)據(jù)庫(kù)類型
  (3). 針對(duì)不通的服務(wù)器和數(shù)據(jù)庫(kù)特點(diǎn)進(jìn)行SQL注入攻擊
• SQL注入攻擊實(shí)例
  比如，在一個(gè)登錄界面，要求輸入用戶名和密碼，可以這樣輸入實(shí)現(xiàn)免帳號(hào)登錄：
  用戶名： ‘or 1 = 1 --
  密 碼：
  用戶一旦點(diǎn)擊登錄，如若沒(méi)有做特殊處理，那么這個(gè)非法用戶就很得意的登陸進(jìn)去了。這是為什么呢?
  下面我們分析一下：從理論上說(shuō)，后臺(tái)認(rèn)證程序中會(huì)有如下的SQL語(yǔ)句：

String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”;

因此，當(dāng)輸入了上面的用戶名和密碼，上面的SQL語(yǔ)句變成：

SELECT * FROM user_table WHERE username=’’or 1 = 1 –- and password=’’

分析上述SQL語(yǔ)句我們知道，username=‘ or 1=1 這個(gè)語(yǔ)句一定會(huì)成功；然后后面加兩個(gè) -，這意味著注釋，它將后面的語(yǔ)句注釋，讓他們不起作用。這樣，上述語(yǔ)句永遠(yuǎn)都能正確執(zhí)行，用戶輕易騙過(guò)系統(tǒng)，獲取合法身份。

• 應(yīng)對(duì)方法
  (1). 參數(shù)綁定
  使用預(yù)編譯手段，綁定參數(shù)是最好的防SQL注入的方法。目前許多的ORM框架及JDBC等都實(shí)現(xiàn)了SQL預(yù)編譯和參數(shù)綁定功能，攻擊者的惡意SQL會(huì)被當(dāng)做SQL的參數(shù)而不是SQL命令被執(zhí)行。在mybatis的mapper文件中，對(duì)于傳遞的參數(shù)我們一般是使用 # 和時(shí)，變量就是直接追加在sql中，一般會(huì)有sql注入問(wèn)題。
  (2). 使用正則表達(dá)式過(guò)濾傳入的參數(shù)

14、談一談 XSS 攻擊，舉個(gè)例子？

XSS是一種經(jīng)常出現(xiàn)在web應(yīng)用中的計(jì)算機(jī)安全漏洞，與SQL注入一起成為web中最主流的攻擊方式。
XSS是指惡意攻擊者利用網(wǎng)站沒(méi)有對(duì)用戶提交數(shù)據(jù)進(jìn)行轉(zhuǎn)義處理或者過(guò)濾不足的缺點(diǎn)，進(jìn)而添加一些腳本代碼嵌入到web頁(yè)面中去，使別的用戶訪問(wèn)都會(huì)執(zhí)行相應(yīng)的嵌入代碼，從而盜取用戶資料、利用用戶身份進(jìn)行某種動(dòng)作或者對(duì)訪問(wèn)者進(jìn)行病毒侵害的一種攻擊方式。

• 1). XSS攻擊的危害
  盜取各類用戶帳號(hào)，如機(jī)器登錄帳號(hào)、用戶網(wǎng)銀帳號(hào)、各類管理員帳號(hào)
  控制企業(yè)數(shù)據(jù)，包括讀取、篡改、添加、刪除企業(yè)敏感數(shù)據(jù)的能力
  盜竊企業(yè)重要的具有商業(yè)價(jià)值的資料
  非法轉(zhuǎn)賬
  強(qiáng)制發(fā)送電子郵件
  網(wǎng)站掛馬
  控制受害者機(jī)器向其它網(wǎng)站發(fā)起攻擊
• 2). 原因解析
  主要原因：過(guò)于信任客戶端提交的數(shù)據(jù)！
  解決辦法：不信任任何客戶端提交的數(shù)據(jù)，只要是客戶端提交的數(shù)據(jù)就應(yīng)該先進(jìn)行相應(yīng)的過(guò)濾處理然后方可進(jìn)行下一步的操作。
  進(jìn)一步分析細(xì)節(jié)：客戶端提交的數(shù)據(jù)本來(lái)就是應(yīng)用所需要的，但是惡意攻擊者利用網(wǎng)站對(duì)客戶端提交數(shù)據(jù)的信任，在數(shù)據(jù)中插入一些符號(hào)以及javascript代碼，那么這些數(shù)據(jù)將會(huì)成為應(yīng)用代碼中的一部分了，那么攻擊者就可以肆無(wú)忌憚地展開(kāi)攻擊啦，因此我們絕不可以信任任何客戶端提交的數(shù)據(jù)?。?！
• 3). XSS 攻擊分類
  (1). 反射性XSS攻擊 (非持久性XSS攻擊)
  漏洞產(chǎn)生的原因是攻擊者注入的數(shù)據(jù)反映在響應(yīng)中。一個(gè)典型的非持久性XSS攻擊包含一個(gè)帶XSS攻擊向量的鏈接(即每次攻擊需要用戶的點(diǎn)擊)，例如，正常發(fā)送消息：
  http://www.test.com/message.php?send=Hello,World！
  接收者將會(huì)接收信息并顯示Hello,World；但是，非正常發(fā)送消息：
  http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！
  接收者接收消息顯示的時(shí)候?qū)?huì)彈出警告窗口！
  (2). 持久性XSS攻擊 (留言板場(chǎng)景)
  XSS攻擊向量(一般指XSS攻擊代碼)存儲(chǔ)在網(wǎng)站數(shù)據(jù)庫(kù)，當(dāng)一個(gè)頁(yè)面被用戶打開(kāi)的時(shí)候執(zhí)行。也就是說(shuō)，每當(dāng)用戶使用瀏覽器打開(kāi)指定頁(yè)面時(shí)，腳本便執(zhí)行。
  與非持久性XSS攻擊相比，持久性XSS攻擊危害性更大。從名字就可以了解到，持久性XSS攻擊就是將攻擊代碼存入數(shù)據(jù)庫(kù)中，然后客戶端打開(kāi)時(shí)就執(zhí)行這些攻擊代碼。
  例如，留言板表單中的表單域：
  <input type="text" name="content" value="這里是用戶填寫(xiě)的數(shù)據(jù)">
  正常操作流程是：用戶是提交相應(yīng)留言信息 —— 將數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù) —— 其他用戶訪問(wèn)留言板，應(yīng)用去數(shù)據(jù)并顯示；而非正常操作流程是攻擊者在value填寫(xiě):
  <script>alert(‘foolish!’)；</script>
  并將數(shù)據(jù)提交、存儲(chǔ)到數(shù)據(jù)庫(kù)中；當(dāng)其他用戶取出數(shù)據(jù)顯示的時(shí)候，將會(huì)執(zhí)行這些攻擊性代碼。
• 4). 修復(fù)漏洞方針
  漏洞產(chǎn)生的根本原因是 太相信用戶提交的數(shù)據(jù)，對(duì)用戶所提交的數(shù)據(jù)過(guò)濾不足所導(dǎo)致的，因此解決方案也應(yīng)該從這個(gè)方面入手，具體方案包括：
  將重要的cookie標(biāo)記為http only, 這樣的話Javascript 中的document.cookie語(yǔ)句就不能獲取到cookie了（如果在cookie中設(shè)置了HttpOnly屬性，那么通過(guò)js腳本將無(wú)法讀取到cookie信息，這樣能有效的防止XSS攻擊）；
  表單數(shù)據(jù)規(guī)定值的類型，例如：年齡應(yīng)為只能為int、name只能為字母數(shù)字組合。。。。
  對(duì)數(shù)據(jù)進(jìn)行Html Encode 處理
  過(guò)濾或移除特殊的Html標(biāo)簽，例如:

15、講一下網(wǎng)絡(luò)五層模型，每一層的職責(zé)？

• 前言
  天各一方的兩臺(tái)計(jì)算機(jī)是如何通信的呢？在成千上萬(wàn)的計(jì)算機(jī)中，為什么一臺(tái)計(jì)算機(jī)能夠準(zhǔn)確著尋找到另外一臺(tái)計(jì)算機(jī)，并且把數(shù)據(jù)發(fā)送給它呢？
  可能很多人都聽(tīng)說(shuō)過(guò)網(wǎng)絡(luò)通信的 5 層模型，但是可能并不是很清楚為什么需要五層模型，五層模型負(fù)責(zé)的任務(wù)也有可能經(jīng)?；煜?。下面是網(wǎng)絡(luò)通信的五層模型
  說(shuō)實(shí)話，五層模型的具體內(nèi)容還是極其復(fù)雜的，不過(guò)今天這篇文章，我將用最簡(jiǎn)潔的模式，通過(guò)網(wǎng)絡(luò)通信的五層模型來(lái)講解一臺(tái)計(jì)算機(jī)是如何找到另外一臺(tái)計(jì)算機(jī)并且把數(shù)據(jù)發(fā)送給另一臺(tái)計(jì)算機(jī)的，就算你沒(méi)學(xué)過(guò)計(jì)算機(jī)網(wǎng)絡(luò)，也能夠聽(tīng)的懂。
• 1. 物理層
     一臺(tái)計(jì)算機(jī)與另一臺(tái)計(jì)算機(jī)要進(jìn)行通信，第一件要做的事是什么？當(dāng)然是要把這臺(tái)計(jì)算機(jī)與另外的其他計(jì)算機(jī)連起來(lái)啊，這樣，我們才能把數(shù)據(jù)傳輸過(guò)去。例如可以通過(guò)光纖啊，電纜啊，雙絞線啊等介質(zhì)把他們連接起來(lái)，然后才能進(jìn)行通信。
     也就是說(shuō)，物理層負(fù)責(zé)把兩臺(tái)計(jì)算機(jī)連起來(lái)，然后在計(jì)算機(jī)之間通過(guò)高低電頻來(lái)傳送0,1這樣的電信號(hào)。
• 2. 數(shù)據(jù)鏈路層
     前面說(shuō)了，物理層它只是單純著負(fù)責(zé)把計(jì)算機(jī)連接起來(lái)，并且在計(jì)算機(jī)之間傳輸0，1這樣的電信號(hào)。如果這些0，1組合的傳送毫無(wú)規(guī)則的話，計(jì)算機(jī)是解讀不了的。一大堆0，1誰(shuí)知道是什么鬼啊。
     因此，我們需要制定一套規(guī)則來(lái)進(jìn)行0，1的傳送。例如多少個(gè)電信號(hào)為一組啊，每一組信號(hào)應(yīng)該如何標(biāo)識(shí)才能讓計(jì)算機(jī)讀懂啊等等。
     于是，有了以太網(wǎng)協(xié)議。
     (1). 以太網(wǎng)協(xié)議
     以太網(wǎng)協(xié)議規(guī)定，一組電信號(hào)構(gòu)成一個(gè)數(shù)據(jù)包，我們把這個(gè)數(shù)據(jù)包稱之為幀。每一個(gè)楨由標(biāo)頭(Head)和數(shù)據(jù)(Data)兩部分組成。
     幀的大小一般為 64 – 1518 個(gè)字節(jié)。假如需要傳送的數(shù)據(jù)很大的話，就分成多個(gè)楨來(lái)進(jìn)行傳送。
     對(duì)于表頭和數(shù)據(jù)這兩個(gè)部分，他們存放的都是一些什么數(shù)據(jù)呢？我猜你瞇著眼睛都能想到他們應(yīng)該放什么數(shù)據(jù)。 毫無(wú)疑問(wèn)，我們至少得知道這個(gè)楨是誰(shuí)發(fā)送，發(fā)送給誰(shuí)的等這些信息吧？所以標(biāo)頭部分主要是一些說(shuō)明數(shù)據(jù)，例如發(fā)送者，接收者等信息。而數(shù)據(jù)部分則是這個(gè)數(shù)據(jù)包具體的，想給接守者的內(nèi)容。
     大家想一個(gè)問(wèn)題，一個(gè)楨的長(zhǎng)度是 64~1518 個(gè)字節(jié)，也就是說(shuō)楨的長(zhǎng)度不是固定的，那你覺(jué)得標(biāo)頭部分的字節(jié)長(zhǎng)度是固定的嗎？它當(dāng)然是固定的啊，假如不是固定的，每個(gè)楨都是單獨(dú)發(fā)的，那計(jì)算機(jī)怎么知道標(biāo)頭是幾個(gè)字節(jié)，數(shù)據(jù)是幾個(gè)字節(jié)呢。所以標(biāo)頭部分的字節(jié)是固定的，并且固定為18個(gè)字節(jié)。
     把一臺(tái)計(jì)算的的數(shù)據(jù)通過(guò)物理層和鏈路層發(fā)送給另一臺(tái)計(jì)算機(jī)，究竟是誰(shuí)發(fā)給誰(shuí)的，計(jì)算機(jī)與計(jì)算機(jī)之間如何區(qū)分，，你總得給他們一個(gè)唯一的標(biāo)識(shí)吧？
     于是，MAC 地址出現(xiàn)了。
     (2). MAC 地址
     連入網(wǎng)絡(luò)的每一個(gè)計(jì)算機(jī)都會(huì)有網(wǎng)卡接口，每一個(gè)網(wǎng)卡都會(huì)有一個(gè)唯一的地址，這個(gè)地址就叫做 MAC 地址。計(jì)算機(jī)之間的數(shù)據(jù)傳送，就是通過(guò) MAC 地址來(lái)唯一尋找、傳送的。
     MAC地址 由 48 個(gè)字節(jié)所構(gòu)成，在網(wǎng)卡生產(chǎn)時(shí)就被唯一標(biāo)識(shí)了。
     (3). 廣播與ARP協(xié)議
     1). 廣播
     如圖，假如計(jì)算機(jī) A 知道了計(jì)算機(jī) B 的 MAC 地址，然后計(jì)算機(jī) A 想要給計(jì)算機(jī) B 傳送數(shù)據(jù)，雖然計(jì)算機(jī) A 知道了計(jì)算機(jī) B 的 MAC 地址，可是它要怎么給它傳送數(shù)據(jù)呢？計(jì)算機(jī) A 不僅連著計(jì)算機(jī) B，而且計(jì)算機(jī) A 也還連著其他的計(jì)算機(jī)。 雖然計(jì)算機(jī) A 知道計(jì)算機(jī) B 的 MAC 地址，可是計(jì)算機(jī) A 卻不知道知道計(jì)算機(jī) B 是分布在哪邊路線上，為了解決這個(gè)問(wèn)題，于是，有了廣播的出現(xiàn)。
     在同一個(gè)子網(wǎng)中，計(jì)算機(jī) A 要向計(jì)算機(jī) B 發(fā)送一個(gè)數(shù)據(jù)包，這個(gè)數(shù)據(jù)包會(huì)包含接收者的 MAC 地址。當(dāng)發(fā)送時(shí)，計(jì)算機(jī) A 是通過(guò)廣播的方式發(fā)送的，這時(shí)同一個(gè)子網(wǎng)中的計(jì)算機(jī) C, D 也會(huì)收到這個(gè)數(shù)據(jù)包的，然后收到這個(gè)數(shù)據(jù)包的計(jì)算機(jī)，會(huì)把數(shù)據(jù)包的 MAC 地址取出來(lái)，與自身的 MAC 地址對(duì)比，如果兩者相同，則接受這個(gè)數(shù)據(jù)包，否則就丟棄這個(gè)數(shù)據(jù)包。這種發(fā)送方式我們稱之為廣播,就像我們平時(shí)在廣場(chǎng)上通過(guò)廣播的形式呼叫某個(gè)人一樣，如果這個(gè)名字是你，你就理會(huì)一下，如果不是你，你就當(dāng)作聽(tīng)不見(jiàn)。
     2). ARP 協(xié)議。
     那么問(wèn)題來(lái)了，計(jì)算機(jī) A 是如何知道計(jì)算機(jī) B 的 MAC 地址的呢？這個(gè)時(shí)候就得由 ARP 協(xié)議這個(gè)家伙來(lái)解決了，不過(guò) ARP 協(xié)議會(huì)涉及到IP地址，我們下面才會(huì)扯到IP地址。因此我們先放著，就當(dāng)作是有這么一個(gè) ARP 協(xié)議，通過(guò)它我們可以知道子網(wǎng)中其他計(jì)算機(jī)的 MAC 地址。
• 3. 網(wǎng)絡(luò)層
     上面我們有說(shuō)到子網(wǎng)這個(gè)關(guān)鍵詞，實(shí)際上我們所處的網(wǎng)絡(luò)，是由無(wú)數(shù)個(gè)子網(wǎng)絡(luò)構(gòu)成的。廣播的時(shí)候，也只有同一個(gè)子網(wǎng)里面的計(jì)算機(jī)能夠收到。
     假如沒(méi)有子網(wǎng)這種劃分的話，計(jì)算機(jī) A 通過(guò)廣播的方式發(fā)一個(gè)數(shù)據(jù)包給計(jì)算機(jī) B , 其他所有計(jì)算機(jī)也都能收到這個(gè)數(shù)據(jù)包，然后進(jìn)行對(duì)比再舍棄。世界上有那么多它計(jì)算機(jī)，每一臺(tái)計(jì)算機(jī)都能收到其他所有計(jì)算機(jī)的數(shù)據(jù)包，那就不得了了。那還不得奔潰。 因此產(chǎn)生了子網(wǎng)這么一個(gè)東西。
     那么問(wèn)題來(lái)了，我們?nèi)绾螀^(qū)分哪些 MAC 地址是屬于同一個(gè)子網(wǎng)的呢？假如是同一個(gè)子網(wǎng)，那我們就用廣播的形式把數(shù)據(jù)傳送給對(duì)方，如果不是同一個(gè)子網(wǎng)的，我們就會(huì)把數(shù)據(jù)發(fā)給網(wǎng)關(guān)，讓網(wǎng)關(guān)進(jìn)行轉(zhuǎn)發(fā)。
     為了解決這個(gè)問(wèn)題，于是，有了 IP 協(xié)議。
     (1). IP協(xié)議
     IP協(xié)議，它所定義的地址，我們稱之為IP地址。IP協(xié)議有兩種版本，一種是 IPv4,另一種是 IPv6。不過(guò)我們目前大多數(shù)用的還是 IPv4，我們現(xiàn)在也只討論 IPv4 這個(gè)版本的協(xié)議。
     這個(gè) IP 地址由 32 位的二進(jìn)制數(shù)組成，我們一般把它分成4段的十進(jìn)制表示，地址范圍為0.0.0.0~255.255.255.255。
     每一臺(tái)想要聯(lián)網(wǎng)的計(jì)算機(jī)都會(huì)有一個(gè)IP地址。這個(gè)IP地址被分為兩部分，前面一部分代表網(wǎng)絡(luò)部分，后面一部分代表主機(jī)部分。并且網(wǎng)絡(luò)部分和主機(jī)部分所占用的二進(jìn)制位數(shù)是不固定的。
     假如兩臺(tái)計(jì)算機(jī)的網(wǎng)絡(luò)部分是一模一樣的，我們就說(shuō)這兩臺(tái)計(jì)算機(jī)是處于同一個(gè)子網(wǎng)中。例如 192.168.43.1 和 192.168.43.2, 假如這兩個(gè) IP 地址的網(wǎng)絡(luò)部分為 24 位，主機(jī)部分為 8 位。那么他們的網(wǎng)絡(luò)部分都為 192.168.43，所以他們處于同一個(gè)子網(wǎng)中。
     可是問(wèn)題來(lái)了，你怎么知道網(wǎng)絡(luò)部分是占幾位，主機(jī)部分又是占幾位呢？也就是說(shuō)，單單從兩臺(tái)計(jì)算機(jī)的IP地址，我們是無(wú)法判斷他們的是否處于同一個(gè)子網(wǎng)中的。
     這就引申出了另一個(gè)關(guān)鍵詞——子網(wǎng)掩碼。子網(wǎng)掩碼和IP地址一樣也是 32 位二進(jìn)制數(shù)，不過(guò)它的網(wǎng)絡(luò)部分規(guī)定全部為 1，主機(jī)部分規(guī)定全部為 0.也就是說(shuō)，假如上面那兩個(gè)IP地址的網(wǎng)絡(luò)部分為 24 位，主機(jī)部分為 8 位的話，那他們的子網(wǎng)掩碼都為 11111111.11111111.11111111.00000000，即255.255.255.0。
     那有了子網(wǎng)掩碼，如何來(lái)判端IP地址是否處于同一個(gè)子網(wǎng)中呢。顯然，知道了子網(wǎng)掩碼，相當(dāng)于我們知道了網(wǎng)絡(luò)部分是幾位，主機(jī)部分是幾位。我們只需要把 IP 地址與它的子網(wǎng)掩碼做與(and)運(yùn)算，然后把各自的結(jié)果進(jìn)行比較就行了，如果比較的結(jié)果相同，則代表是同一個(gè)子網(wǎng)，否則不是同一個(gè)子網(wǎng)。
     例如，192.168.43.1和192.168.43.2的子碼掩碼都為255.255.255.0，把IP與子碼掩碼相與，可以得到他們都為192.168.43.0，進(jìn)而他們處于同一個(gè)子網(wǎng)中。
     (2). ARP協(xié)議
     有了上面IP協(xié)議的知識(shí)，我們回來(lái)講一下ARP協(xié)議。
     有了兩臺(tái)計(jì)算機(jī)的IP地址與子網(wǎng)掩碼，我們就可以判斷出它們是否處于同一個(gè)子網(wǎng)之中了。
     假如他們處于同一個(gè)子網(wǎng)之中，計(jì)算機(jī)A要給計(jì)算機(jī)B發(fā)送數(shù)據(jù)時(shí)。我們可以通過(guò)ARP協(xié)議來(lái)得到計(jì)算機(jī)B的MAC地址。
     ARP協(xié)議也是通過(guò)廣播的形式給同一個(gè)子網(wǎng)中的每臺(tái)電腦發(fā)送一個(gè)數(shù)據(jù)包(當(dāng)然，這個(gè)數(shù)據(jù)包會(huì)包含接收方的IP地址)。對(duì)方收到這個(gè)數(shù)據(jù)包之后，會(huì)取出IP地址與自身的對(duì)比，如果相同，則把自己的MAC地址回復(fù)給對(duì)方，否則就丟棄這個(gè)數(shù)據(jù)包。這樣，計(jì)算機(jī)A就能知道計(jì)算機(jī)B的MAC地址了。
     可能有人會(huì)問(wèn)，知道了MAC地址之后，發(fā)送數(shù)據(jù)是通過(guò)廣播的形式發(fā)送，詢問(wèn)對(duì)方的MAC地址也是通過(guò)廣播的形式來(lái)發(fā)送，那其他計(jì)算機(jī)怎么知道你是要傳送數(shù)據(jù)還是要詢問(wèn)MAC地址呢？其實(shí)在詢問(wèn)MAC地址的數(shù)據(jù)包中，在對(duì)方的MAC地址這一欄中，填的是一個(gè)特殊的MAC地址，其他計(jì)算機(jī)看到這個(gè)特殊的MAC地址之后，就能知道廣播想干嘛了。
     假如兩臺(tái)計(jì)算機(jī)的IP不是處于同一個(gè)子網(wǎng)之中，這個(gè)時(shí)候，我們就會(huì)把數(shù)據(jù)包發(fā)送給網(wǎng)關(guān)，然后讓網(wǎng)關(guān)讓我們進(jìn)行轉(zhuǎn)發(fā)傳送
     (3). DNS服務(wù)器
     這里再說(shuō)一個(gè)問(wèn)題，我們是如何知道對(duì)方計(jì)算機(jī)的IP地址的呢？這個(gè)問(wèn)題可能有人會(huì)覺(jué)得很白癡，心想，當(dāng)然是計(jì)算機(jī)的操作者來(lái)進(jìn)行輸入了。這沒(méi)錯(cuò)，當(dāng)我們想要訪問(wèn)某個(gè)網(wǎng)站的時(shí)候，我們可以輸入IP來(lái)進(jìn)行訪問(wèn)，但是我相信絕大多數(shù)人是輸入一個(gè)網(wǎng)址域名的，例如訪問(wèn)百度是輸入 www.baidu.com 這個(gè)域名。其實(shí)當(dāng)我們輸入這個(gè)域名時(shí)，會(huì)有一個(gè)叫做DNS服務(wù)器的家伙來(lái)幫我們解析這個(gè)域名，然后返回這個(gè)域名對(duì)應(yīng)的IP給我們的。
     因此，網(wǎng)絡(luò)層的功能就是讓我們?cè)诿ＣＨ撕Ｖ?，能夠找到另一臺(tái)計(jì)算機(jī)在哪里，是否屬于同一個(gè)子網(wǎng)等。
• 4. 傳輸層
     通過(guò)物理層、數(shù)據(jù)鏈路層以及網(wǎng)絡(luò)層的互相幫助，我們已經(jīng)把數(shù)據(jù)成功從計(jì)算機(jī)A傳送到計(jì)算機(jī)B了，可是，計(jì)算機(jī)B里面有各種各樣的應(yīng)用程序，計(jì)算機(jī)該如何知道這些數(shù)據(jù)是給誰(shuí)的呢？
     這個(gè)時(shí)候，端口(Port)這個(gè)家伙就上場(chǎng)了，也就是說(shuō)，我們?cè)趶挠?jì)算機(jī)A傳數(shù)據(jù)給計(jì)算機(jī)B的時(shí)候，還得指定一個(gè)端口，以供特定的應(yīng)用程序來(lái)接受處理。
     也就是說(shuō)，傳輸層的功能就是建立端口到端口的通信。相比網(wǎng)絡(luò)層的功能是建立主機(jī)到主機(jī)的通信。
     也就是說(shuō)，只有有了IP和端口，我們才能進(jìn)行準(zhǔn)確著通信。這個(gè)時(shí)候可能有人會(huì)說(shuō)，我輸入IP地址的時(shí)候并沒(méi)有指定一個(gè)端口啊。其實(shí)呢，對(duì)于有些傳輸協(xié)議，已經(jīng)有設(shè)定了一些默認(rèn)端口了。例如http的傳輸默認(rèn)端口是80，這些端口信息也會(huì)包含在數(shù)據(jù)包里的。
     傳輸層最常見(jiàn)的兩大協(xié)議是 TCP 協(xié)議和 UDP 協(xié)議，其中 TCP 協(xié)議與 UDP 最大的不同就是 TCP 提供可靠的傳輸，而 UDP 提供的是不可靠傳輸。
• 5. 應(yīng)用層
     終于說(shuō)到應(yīng)用層了，應(yīng)用層這一層最接近我們用戶了。
     雖然我們收到了傳輸層傳來(lái)的數(shù)據(jù)，可是這些傳過(guò)來(lái)的數(shù)據(jù)五花八門(mén)，有html格式的，有mp4格式的，各種各樣。你確定你能看的懂？
     因此我們需要指定這些數(shù)據(jù)的格式規(guī)則，收到后才好解讀渲染。例如我們最常見(jiàn)的 Http 數(shù)據(jù)包中，就會(huì)指定該數(shù)據(jù)包是 什么格式的文件了。
• 總結(jié)
  五層模型至此講到這里。對(duì)于有些層講的比較簡(jiǎn)潔，就隨便概況了一下。因?yàn)槿绻艺f(shuō)的詳細(xì)一點(diǎn)的話，篇幅肯定會(huì)特別特別長(zhǎng)，我著已經(jīng)是盡最大的努力以最簡(jiǎn)潔的方式來(lái)講的了。如果你想詳細(xì)去了解，可以去買(mǎi)計(jì)算機(jī)網(wǎng)絡(luò)相應(yīng)的資料，強(qiáng)烈推薦《計(jì)算機(jī)網(wǎng)絡(luò)：自頂向下》這本書(shū)。希望我的講解能讓你對(duì)計(jì)算機(jī)之間數(shù)據(jù)的傳輸有個(gè)大概的了解。

16、簡(jiǎn)單說(shuō)下 HTTPS 和 HTTP 的區(qū)別

Http協(xié)議運(yùn)行在TCP之上，明文傳輸，客戶端與服務(wù)器端都無(wú)法驗(yàn)證對(duì)方的身份；Https是身披SSL(Secure Socket Layer)外殼的Http，運(yùn)行于SSL上，SSL運(yùn)行于TCP之上，是添加了加密和認(rèn)證機(jī)制的HTTP。二者之間存在如下不同：

• 1、端口不同：Http與Https使用不同的連接方式，用的端口也不一樣，前者是80，后者是443；
• 2、資源消耗：和HTTP通信相比，Https通信會(huì)由于加減密處理消耗更多的CPU和內(nèi)存資源；
• 3、開(kāi)銷(xiāo)：Https通信需要證書(shū)，而證書(shū)一般需要向認(rèn)證機(jī)構(gòu)購(gòu)買(mǎi)；
  Https的加密機(jī)制是一種共享密鑰加密和公開(kāi)密鑰加密并用的混合加密機(jī)制。

17、對(duì)稱加密與非對(duì)稱加密的區(qū)別

對(duì)稱密鑰加密是指加密和解密使用同一個(gè)密鑰的方式，這種方式存在的最大問(wèn)題就是密鑰發(fā)送問(wèn)題，即如何安全地將密鑰發(fā)給對(duì)方。
非對(duì)稱加密是指使用一對(duì)非對(duì)稱密鑰，即公鑰和私鑰，公鑰可以隨意發(fā)布，但私鑰只有自己知道。發(fā)送密文的一方使用對(duì)方的公鑰進(jìn)行加密處理，對(duì)方接收到加密信息后，使用自己的私鑰進(jìn)行解密。
由于非對(duì)稱加密的方式不需要發(fā)送用來(lái)解密的私鑰，所以可以保證安全性；但是和對(duì)稱加密比起來(lái)，它非常的慢，所以我們還是要用對(duì)稱加密來(lái)傳送消息，但對(duì)稱加密所使用的密鑰我們可以通過(guò)非對(duì)稱加密的方式發(fā)送出去。

18、簡(jiǎn)單說(shuō)下每一層對(duì)應(yīng)的網(wǎng)絡(luò)協(xié)議有哪些？

計(jì)算機(jī)五層網(wǎng)絡(luò)體系中涉及的協(xié)議非常多，下面就常用的做了列舉：

19、ARP 協(xié)議的工作原理？

網(wǎng)絡(luò)層的 ARP 協(xié)議完成了IP 地址與物理地址的映射。首先，每臺(tái)主機(jī)都會(huì)在自己的 ARP 緩沖區(qū)中建立一個(gè) ARP 列表，以表示 IP 地址和 MAC 地址的對(duì)應(yīng)關(guān)系。當(dāng)源主機(jī)需要將一個(gè)數(shù)據(jù)包要發(fā)送到目的主機(jī)時(shí)，會(huì)首先檢查自己 ARP 列表中是否存在該 IP 地址對(duì)應(yīng)的 MAC 地址：如果有，就直接將數(shù)據(jù)包發(fā)送到這個(gè) MAC 地址；如果沒(méi)有，就向本地網(wǎng)段發(fā)起一個(gè) ARP 請(qǐng)求的廣播包，查詢此目的主機(jī)對(duì)應(yīng)的 MAC 地址。
此 ARP 請(qǐng)求數(shù)據(jù)包里包括源主機(jī)的 IP 地址、硬件地址、以及目的主機(jī)的 IP 地址。網(wǎng)絡(luò)中所有的主機(jī)收到這個(gè) ARP 請(qǐng)求后，會(huì)檢查數(shù)據(jù)包中的目的 IP 是否和自己的 IP 地址一致。如果不相同就忽略此數(shù)據(jù)包；如果相同，該主機(jī)首先將發(fā)送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已經(jīng)存在該 IP 的信息，則將其覆蓋，然后給源主機(jī)發(fā)送一個(gè) ARP 響應(yīng)數(shù)據(jù)包，告訴對(duì)方自己是它需要查找的 MAC 地址；源主機(jī)收到這個(gè) ARP 響應(yīng)數(shù)據(jù)包后，將得到的目的主機(jī)的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息開(kāi)始數(shù)據(jù)的傳輸。如果源主機(jī)一直沒(méi)有收到 ARP 響應(yīng)數(shù)據(jù)包，表示 ARP 查詢失敗

20、TCP的主要特點(diǎn)

• 1 TCP 是面向連接的。（就好像打電話一樣，通話前需要先撥號(hào)建立連接，通話結(jié)束后要掛機(jī)釋放連接）；
• 2 每一條 TCP 連接只能有兩個(gè)端點(diǎn)，每一條 TCP 連接只能是點(diǎn)對(duì)點(diǎn)的（一對(duì)一）；
• 3 TCP 提供可靠交付的服務(wù)。通過(guò) TCP 連接傳送的數(shù)據(jù)，無(wú)差錯(cuò)、不丟失、不重復(fù)、并且按序到達(dá)；
• 4 TCP 提供全雙工通信。TCP 允許通信雙方的應(yīng)用進(jìn)程在任何時(shí)候都能發(fā)送數(shù)據(jù)。TCP 連接的兩端都設(shè)有發(fā)送緩存和接收緩存，用來(lái)臨時(shí)存放雙方通信的數(shù)據(jù)；
• 5 面向字節(jié)流。TCP 中的“流”（Stream）指的是流入進(jìn)程或從進(jìn)程流出的字節(jié)序列?！懊嫦蜃止?jié)流”的含義是：雖然應(yīng)用程序和 TCP 的交互是一次一個(gè)數(shù)據(jù)塊（大小不等），但 TCP 把應(yīng)用程序交下來(lái)的數(shù)據(jù)僅僅看成是一連串的無(wú)結(jié)構(gòu)的字節(jié)流。

21、UDP 的主要特點(diǎn)是什么？

• 1 UDP 是無(wú)連接的；
• 2 UDP 使用盡最大努力交付，即不保證可靠交付，因此主機(jī)不需要維持復(fù)雜的鏈接狀態(tài)（這里面有許多參數(shù)）；
• 3 UDP 是面向報(bào)文的；
• 4 UDP 沒(méi)有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使源主機(jī)的發(fā)送速率降低（對(duì)實(shí)時(shí)應(yīng)用很有用，如 直播，實(shí)時(shí)視頻會(huì)議等）；
• 5 UDP 支持一對(duì)一、一對(duì)多、多對(duì)一和多對(duì)多的交互通信；
• 6 UDP 的首部開(kāi)銷(xiāo)小，只有 8 個(gè)字節(jié)，比 TCP 的 20 個(gè)字節(jié)的首部要短。

22、TCP 和 UDP 分別對(duì)應(yīng)的常見(jiàn)應(yīng)用層協(xié)議有哪些？

• 1. TCP 對(duì)應(yīng)的應(yīng)用層協(xié)議
     FTP：定義了文件傳輸協(xié)議，使用 21 端口。常說(shuō)某某計(jì)算機(jī)開(kāi)了 FTP 服務(wù)便是啟動(dòng)了文件傳輸服務(wù)。下載文件，上傳主頁(yè)，都要用到 FTP 服務(wù)。
     Telnet：它是一種用于遠(yuǎn)程登陸的端口，用戶可以以自己的身份遠(yuǎn)程連接到計(jì)算機(jī)上，通過(guò)這種端口可以提供一種基于 DOS 模式下的通信服務(wù)。如以前的 BBS 是-純字符界面的，支持 BBS 的服務(wù)器將 23 端口打開(kāi)，對(duì)外提供服務(wù)。
     SMTP：定義了簡(jiǎn)單郵件傳送協(xié)議，現(xiàn)在很多郵件服務(wù)器都用的是這個(gè)協(xié)議，用于發(fā)送郵件。如常見(jiàn)的免費(fèi)郵件服務(wù)中用的就是這個(gè)郵件服務(wù)端口，所以在電子郵件設(shè)置-中?？吹接羞@么 SMTP 端口設(shè)置這個(gè)欄，服務(wù)器開(kāi)放的是 25 號(hào)端口。
     POP3：它是和 SMTP 對(duì)應(yīng)，POP3 用于接收郵件。通常情況下，POP3 協(xié)議所用的是 110 端口。也是說(shuō)，只要你有相應(yīng)的使用 POP3 協(xié)議的程序（例如 Fo-xmail 或 Outlook），就可以不以 Web 方式登陸進(jìn)郵箱界面，直接用郵件程序就可以收到郵件（如是163 郵箱就沒(méi)有必要先進(jìn)入網(wǎng)易網(wǎng)站，再進(jìn)入自己的郵-箱來(lái)收信）。
     HTTP：從 Web 服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。
• 2. UDP 對(duì)應(yīng)的應(yīng)用層協(xié)議
     DNS：用于域名解析服務(wù)，將域名地址轉(zhuǎn)換為 IP 地址。DNS 用的是 53 號(hào)端口。
     SNMP：簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議，使用 161 號(hào)端口，是用來(lái)管理網(wǎng)絡(luò)設(shè)備的。由于網(wǎng)絡(luò)設(shè)備很多，無(wú)連接的服務(wù)就體現(xiàn)出其優(yōu)勢(shì)。
     TFTP(Trival File Transfer Protocal)：簡(jiǎn)單文件傳輸協(xié)議，該協(xié)議在熟知端口 69 上使用 UDP 服務(wù)。

23、為什么 TIME-WAIT 狀態(tài)必須等待 2MSL 的時(shí)間呢？

• 1、為了保證 A 發(fā)送的最后一個(gè) ACK 報(bào)文段能夠到達(dá) B。這個(gè) ACK 報(bào)文段有可能丟失，因而使處在 LAST-ACK 狀態(tài)的 B 收不到對(duì)已發(fā)送的 FIN + ACK 報(bào)文段的確認(rèn)。B 會(huì)超時(shí)重傳這個(gè) FIN+ACK 報(bào)文段，而 A 就能在 2MSL 時(shí)間內(nèi)（超時(shí) + 1MSL 傳輸）收到這個(gè)重傳的 FIN+ACK 報(bào)文段。接著 A 重傳一次確認(rèn)，重新啟動(dòng) 2MSL 計(jì)時(shí)器。最后，A 和 B 都正常進(jìn)入到 CLOSED 狀態(tài)。如果 A 在 TIME-WAIT 狀態(tài)不等待一段時(shí)間，而是在發(fā)送完 ACK 報(bào)文段后立即釋放連接，那么就無(wú)法收到 B 重傳的 FIN + ACK 報(bào)文段，因而也不會(huì)再發(fā)送一次確認(rèn)報(bào)文段，這樣，B 就無(wú)法按照正常步驟進(jìn)入 CLOSED 狀態(tài)。
• 2、 防止已失效的連接請(qǐng)求報(bào)文段出現(xiàn)在本連接中。A 在發(fā)送完最后一個(gè) ACK 報(bào)文段后，再經(jīng)過(guò)時(shí)間 2MSL，就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失。這樣就可以使下一個(gè)連接中不會(huì)出現(xiàn)這種舊的連接請(qǐng)求報(bào)文段。

24、保活計(jì)時(shí)器的作用？

除時(shí)間等待計(jì)時(shí)器外，TCP 還有一個(gè)?；钣?jì)時(shí)器（keepalive timer）。設(shè)想這樣的場(chǎng)景：客戶已主動(dòng)與服務(wù)器建立了 TCP 連接。但后來(lái)客戶端的主機(jī)突然發(fā)生故障。顯然，服務(wù)器以后就不能再收到客戶端發(fā)來(lái)的數(shù)據(jù)。因此，應(yīng)當(dāng)有措施使服務(wù)器不要再白白等待下去。這就需要使用?；钣?jì)時(shí)器了。
服務(wù)器每收到一次客戶的數(shù)據(jù)，就重新設(shè)置?；钣?jì)時(shí)器，時(shí)間的設(shè)置通常是兩個(gè)小時(shí)。若兩個(gè)小時(shí)都沒(méi)有收到客戶端的數(shù)據(jù)，服務(wù)端就發(fā)送一個(gè)探測(cè)報(bào)文段，以后則每隔 75 秒鐘發(fā)送一次。若連續(xù)發(fā)送 10個(gè) 探測(cè)報(bào)文段后仍然無(wú)客戶端的響應(yīng)，服務(wù)端就認(rèn)為客戶端出了故障，接著就關(guān)閉這個(gè)連接。

25、TCP 協(xié)議是如何保證可靠傳輸?shù)模?/h4>

• 數(shù)據(jù)包校驗(yàn)：目的是檢測(cè)數(shù)據(jù)在傳輸過(guò)程中的任何變化，若校驗(yàn)出包有錯(cuò)，則丟棄報(bào)文段并且不給出響應(yīng)，這時(shí) TCP 發(fā)送數(shù)據(jù)端超時(shí)后會(huì)重發(fā)數(shù)據(jù)；
• 對(duì)失序數(shù)據(jù)包重排序：既然 TCP 報(bào)文段作為 IP 數(shù)據(jù)報(bào)來(lái)傳輸，而 IP 數(shù)據(jù)報(bào)的到達(dá)可能會(huì)失序，因此 TCP 報(bào)文段的到達(dá)也可能會(huì)失序。TCP 將對(duì)失序數(shù)據(jù)進(jìn)行重新排序，然后才交給應(yīng)用層；
• 丟棄重復(fù)數(shù)據(jù)：對(duì)于重復(fù)數(shù)據(jù)，能夠丟棄重復(fù)數(shù)據(jù)；
• 應(yīng)答機(jī)制：當(dāng) TCP 收到發(fā)自 TCP 連接另一端的數(shù)據(jù)，它將發(fā)送一個(gè)確認(rèn)。這個(gè)確認(rèn)不是立即發(fā)送，通常將推遲幾分之一秒；
• 超時(shí)重發(fā)：當(dāng) TCP 發(fā)出一個(gè)段后，它啟動(dòng)一個(gè)定時(shí)器，等待目的端確認(rèn)收到這個(gè)報(bào)文段。如果不能及時(shí)收到一個(gè)確認(rèn)，將重發(fā)這個(gè)報(bào)文段；
• 流量控制：TCP 連接的每一方都有固定大小的緩沖空間。TCP 的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)，這可以防止較快主機(jī)致使較慢主機(jī)的緩沖區(qū)溢出，這就是流量控制。TCP 使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議。

26、談?wù)勀銓?duì)停止等待協(xié)議的理解？

停止等待協(xié)議是為了實(shí)現(xiàn)可靠傳輸，它的基本原理就是每發(fā)完一個(gè)分組就停止發(fā)送，等待對(duì)方確認(rèn)。在收到確認(rèn)后再發(fā)下一個(gè)分組；在停止等待協(xié)議中，若接收方收到重復(fù)分組，就丟棄該分組，但同時(shí)還要發(fā)送確認(rèn)。主要包括以下幾種情況：無(wú)差錯(cuò)情況、出現(xiàn)差錯(cuò)情況（超時(shí)重傳）、確認(rèn)丟失和確認(rèn)遲到、確認(rèn)丟失和確認(rèn)遲到。

27、談?wù)勀銓?duì) ARQ 協(xié)議的理解？

• 自動(dòng)重傳請(qǐng)求 ARQ 協(xié)議
  停止等待協(xié)議中超時(shí)重傳是指只要超過(guò)一段時(shí)間仍然沒(méi)有收到確認(rèn)，就重傳前面發(fā)送過(guò)的分組（認(rèn)為剛才發(fā)送過(guò)的分組丟失了）。因此每發(fā)送完一個(gè)分組需要設(shè)置一個(gè)超時(shí)計(jì)時(shí)器，其重傳時(shí)間應(yīng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r(shí)間更長(zhǎng)一些。這種自動(dòng)重傳方式常稱為自動(dòng)重傳請(qǐng)求 ARQ。
• 連續(xù) ARQ 協(xié)議
  連續(xù) ARQ 協(xié)議可提高信道利用率。發(fā)送方維持一個(gè)發(fā)送窗口，凡位于發(fā)送窗口內(nèi)的分組可以連續(xù)發(fā)送出去，而不需要等待對(duì)方確認(rèn)。接收方一般采用累計(jì)確認(rèn)，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)，表明到這個(gè)分組為止的所有分組都已經(jīng)正確收到了。

28、談?wù)勀銓?duì)滑動(dòng)窗口的了解？

TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制的機(jī)制?；瑒?dòng)窗口（Sliding window）是一種流量控制技術(shù)。早期的網(wǎng)絡(luò)通信中，通信雙方不會(huì)考慮網(wǎng)絡(luò)的擁擠情況直接發(fā)送數(shù)據(jù)。由于大家不知道網(wǎng)絡(luò)擁塞狀況，同時(shí)發(fā)送數(shù)據(jù)，導(dǎo)致中間節(jié)點(diǎn)阻塞掉包，誰(shuí)也發(fā)不了數(shù)據(jù)，所以就有了滑動(dòng)窗口機(jī)制來(lái)解決此問(wèn)題。
TCP 中采用滑動(dòng)窗口來(lái)進(jìn)行傳輸控制，滑動(dòng)窗口的大小意味著接收方還有多大的緩沖區(qū)可以用于接收數(shù)據(jù)。發(fā)送方可以通過(guò)滑動(dòng)窗口的大小來(lái)確定應(yīng)該發(fā)送多少字節(jié)的數(shù)據(jù)。當(dāng)滑動(dòng)窗口為 0 時(shí)，發(fā)送方一般不能再發(fā)送數(shù)據(jù)報(bào)，但有兩種情況除外，一種情況是可以發(fā)送緊急數(shù)據(jù)，例如，允許用戶終止在遠(yuǎn)端機(jī)上的運(yùn)行進(jìn)程。另一種情況是發(fā)送方可以發(fā)送一個(gè) 1 字節(jié)的數(shù)據(jù)報(bào)來(lái)通知接收方重新聲明它希望接收的下一字節(jié)及發(fā)送方的滑動(dòng)窗口大小。

29、談下你對(duì)流量控制的理解？

TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來(lái)得及接收。接收方發(fā)送的確認(rèn)報(bào)文中的窗口字段可以用來(lái)控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將窗口字段設(shè)置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

30、談下你對(duì) TCP 擁塞控制的理解？使用了哪些算法？

擁塞控制和流量控制不同，前者是一個(gè)全局性的過(guò)程，而后者指點(diǎn)對(duì)點(diǎn)通信量的控制。在某段時(shí)間，若對(duì)網(wǎng)絡(luò)中某一資源的需求超過(guò)了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就要變壞。這種情況就叫擁塞。
擁塞控制就是為了防止過(guò)多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，這樣就可以使網(wǎng)絡(luò)中的路由器或鏈路不至于過(guò)載。擁塞控制所要做的都有一個(gè)前提，就是網(wǎng)絡(luò)能夠承受現(xiàn)有的網(wǎng)絡(luò)負(fù)荷。擁塞控制是一個(gè)全局性的過(guò)程，涉及到所有的主機(jī)，所有的路由器，以及與降低網(wǎng)絡(luò)傳輸性能有關(guān)的所有因素。相反，流量控制往往是點(diǎn)對(duì)點(diǎn)通信量的控制，是個(gè)端到端的問(wèn)題。流量控制所要做到的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來(lái)得及接收。
為了進(jìn)行擁塞控制，TCP 發(fā)送方要維持一個(gè)擁塞窗口(cwnd) 的狀態(tài)變量。擁塞控制窗口的大小取決于網(wǎng)絡(luò)的擁塞程度，并且動(dòng)態(tài)變化。發(fā)送方讓自己的發(fā)送窗口取為擁塞窗口和接收方的接受窗口中較小的一個(gè)。
TCP 的擁塞控制采用了四種算法，即：慢開(kāi)始、擁塞避免、快重傳和快恢復(fù)。在網(wǎng)絡(luò)層也可以使路由器采用適當(dāng)?shù)姆纸M丟棄策略（如：主動(dòng)隊(duì)列管理 AQM），以減少網(wǎng)絡(luò)擁塞的發(fā)生。

• 慢開(kāi)始：
  慢開(kāi)始算法的思路是當(dāng)主機(jī)開(kāi)始發(fā)送數(shù)據(jù)時(shí)，如果立即把大量數(shù)據(jù)字節(jié)注入到網(wǎng)絡(luò)，那么可能會(huì)引起網(wǎng)絡(luò)阻塞，因?yàn)楝F(xiàn)在還不知道網(wǎng)絡(luò)的符合情況。經(jīng)驗(yàn)表明，較好的方法是先探測(cè)一下，即由小到大逐漸增大發(fā)送窗口，也就是由小到大逐漸增大擁塞窗口數(shù)值。cwnd 初始值為 1，每經(jīng)過(guò)一個(gè)傳播輪次，cwnd 加倍。
• 擁塞避免：
  擁塞避免算法的思路是讓擁塞窗口cwnd緩慢增大，即每經(jīng)過(guò)一個(gè)往返時(shí)間RTT就把發(fā)送方的cwnd加1。
• 快重傳與快恢復(fù)：
  在 TCP/IP 中，快速重傳和快恢復(fù)（fast retransmit and recovery，F(xiàn)RR）是一種擁塞控制算法，它能快速恢復(fù)丟失的數(shù)據(jù)包。
  沒(méi)有 FRR，如果數(shù)據(jù)包丟失了，TCP 將會(huì)使用定時(shí)器來(lái)要求傳輸暫停。在暫停的這段時(shí)間內(nèi)，沒(méi)有新的或復(fù)制的數(shù)據(jù)包被發(fā)送。有了 FRR，如果接收機(jī)接收到一個(gè)不按順序的數(shù)據(jù)段，它會(huì)立即給發(fā)送機(jī)發(fā)送一個(gè)重復(fù)確認(rèn)。如果發(fā)送機(jī)接收到三個(gè)重復(fù)確認(rèn)，它會(huì)假定確認(rèn)件指出的數(shù)據(jù)段丟失了，并立即重傳這些丟失的數(shù)據(jù)段。
  有了 FRR，就不會(huì)因?yàn)橹貍鲿r(shí)要求的暫停被耽誤。當(dāng)有單獨(dú)的數(shù)據(jù)包丟失時(shí)，快速重傳和快恢復(fù)（FRR）能最有效地工作。當(dāng)有多個(gè)數(shù)據(jù)信息包在某一段很短的時(shí)間內(nèi)丟失時(shí)，它則不能很有效地工作。

31、什么是粘包？

在進(jìn)行 Java NIO 學(xué)習(xí)時(shí)，可能會(huì)發(fā)現(xiàn)：如果客戶端連續(xù)不斷的向服務(wù)端發(fā)送數(shù)據(jù)包時(shí)，服務(wù)端接收的數(shù)據(jù)會(huì)出現(xiàn)兩個(gè)數(shù)據(jù)包粘在一起的情況。
TCP 是基于字節(jié)流的，雖然應(yīng)用層和 TCP 傳輸層之間的數(shù)據(jù)交互是大小不等的數(shù)據(jù)塊，但是 TCP 把這些數(shù)據(jù)塊僅僅看成一連串無(wú)結(jié)構(gòu)的字節(jié)流，沒(méi)有邊界；
從 TCP 的幀結(jié)構(gòu)也可以看出，在 TCP 的首部沒(méi)有表示數(shù)據(jù)長(zhǎng)度的字段。
基于上面兩點(diǎn)，在使用 TCP 傳輸數(shù)據(jù)時(shí)，才有粘包或者拆包現(xiàn)象發(fā)生的可能。一個(gè)數(shù)據(jù)包中包含了發(fā)送端發(fā)送的兩個(gè)數(shù)據(jù)包的信息，這種現(xiàn)象即為粘包。
接收端收到了兩個(gè)數(shù)據(jù)包，但是這兩個(gè)數(shù)據(jù)包要么是不完整的，要么就是多出來(lái)一塊，這種情況即發(fā)生了拆包和粘包。拆包和粘包的問(wèn)題導(dǎo)致接收端在處理的時(shí)候會(huì)非常困難，因?yàn)闊o(wú)法區(qū)分一個(gè)完整的數(shù)據(jù)包。
32、TCP 粘包是怎么產(chǎn)生的？

• 發(fā)送方產(chǎn)生粘包
  采用 TCP 協(xié)議傳輸數(shù)據(jù)的客戶端與服務(wù)器經(jīng)常是保持一個(gè)長(zhǎng)連接的狀態(tài)（一次連接發(fā)一次數(shù)據(jù)不存在粘包），雙方在連接不斷開(kāi)的情況下，可以一直傳輸數(shù)據(jù)。但當(dāng)發(fā)送的數(shù)據(jù)包過(guò)于的小時(shí)，那么 TCP 協(xié)議默認(rèn)的會(huì)啟用 Nagle 算法，將這些較小的數(shù)據(jù)包進(jìn)行合并發(fā)送（緩沖區(qū)數(shù)據(jù)發(fā)送是一個(gè)堆壓的過(guò)程）；這個(gè)合并過(guò)程就是在發(fā)送緩沖區(qū)中進(jìn)行的，也就是說(shuō)數(shù)據(jù)發(fā)送出來(lái)它已經(jīng)是粘包的狀態(tài)了。
• 接收方產(chǎn)生粘包
  接收方采用 TCP 協(xié)議接收數(shù)據(jù)時(shí)的過(guò)程是這樣的：數(shù)據(jù)到接收方，從網(wǎng)絡(luò)模型的下方傳遞至傳輸層，傳輸層的 TCP 協(xié)議處理是將其放置接收緩沖區(qū)，然后由應(yīng)用層來(lái)主動(dòng)獲?。– 語(yǔ)言用 recv、read 等函數(shù)）；這時(shí)會(huì)出現(xiàn)一個(gè)問(wèn)題，就是我們?cè)诔绦蛑姓{(diào)用的讀取數(shù)據(jù)函數(shù)不能及時(shí)的把緩沖區(qū)中的數(shù)據(jù)拿出來(lái)，而下一個(gè)數(shù)據(jù)又到來(lái)并有一部分放入的緩沖區(qū)末尾，等我們讀取數(shù)據(jù)時(shí)就是一個(gè)粘包。（放數(shù)據(jù)的速度 > 應(yīng)用層拿數(shù)據(jù)速度）

33、怎么解決拆包和粘包？

分包機(jī)制一般有兩個(gè)通用的解決方法：

• 1 特殊字符控制；
• 2 在包頭首都添加數(shù)據(jù)包的長(zhǎng)度。
  如果使用 netty 的話，就有專門(mén)的編碼器和解碼器解決拆包和粘包問(wèn)題了。
  tips：UDP 沒(méi)有粘包問(wèn)題，但是有丟包和亂序。不完整的包是不會(huì)有的，收到的都是完全正確的包。傳送的數(shù)據(jù)單位協(xié)議是 UDP 報(bào)文或用戶數(shù)據(jù)報(bào)，發(fā)送的時(shí)候既不合并，也不拆分。

34、forward 和 redirect 的區(qū)別？

Forward 和 Redirect 代表了兩種請(qǐng)求轉(zhuǎn)發(fā)方式：直接轉(zhuǎn)發(fā)和間接轉(zhuǎn)發(fā)。

• 直接轉(zhuǎn)發(fā)方式（Forward）：客戶端和瀏覽器只發(fā)出一次請(qǐng)求，Servlet、HTML、JSP 或其它信息資源，由第二個(gè)信息資源響應(yīng)該請(qǐng)求，在請(qǐng)求對(duì)象 request 中，保存的對(duì)象對(duì)于每個(gè)信息資源是共享的。
• 間接轉(zhuǎn)發(fā)方式（Redirect）：實(shí)際是兩次 HTTP 請(qǐng)求，服務(wù)器端在響應(yīng)第一次請(qǐng)求的時(shí)候，讓瀏覽器再向另外一個(gè) URL 發(fā)出請(qǐng)求，從而達(dá)到轉(zhuǎn)發(fā)的目的。
  舉個(gè)通俗的例子：
  直接轉(zhuǎn)發(fā)就相當(dāng)于：“A 找 B 借錢(qián)，B 說(shuō)沒(méi)有，B 去找 C 借，借到借不到都會(huì)把消息傳遞給 A”；
  間接轉(zhuǎn)發(fā)就相當(dāng)于：”A 找 B 借錢(qián)，B 說(shuō)沒(méi)有，讓 A 去找 C 借”。

35、HTTP 方法有哪些？

客戶端發(fā)送的 請(qǐng)求報(bào)文 第一行為請(qǐng)求行，包含了方法字段。
GET：獲取資源，當(dāng)前網(wǎng)絡(luò)中絕大部分使用的都是 GET；
HEAD：獲取報(bào)文首部，和 GET 方法類似，但是不返回報(bào)文實(shí)體主體部分；
POST：傳輸實(shí)體主體
PUT：上傳文件，由于自身不帶驗(yàn)證機(jī)制，任何人都可以上傳文件，因此存在安全性問(wèn)題，一般不使用該方法。
PATCH：對(duì)資源進(jìn)行部分修改。PUT 也可以用于修改資源，但是只能完全替代原始資源，PATCH 允許部分修改。
OPTIONS：查詢指定的 URL 支持的方法；
CONNECT：要求在與代理服務(wù)器通信時(shí)建立隧道。使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸。
TRACE：追蹤路徑。服務(wù)器會(huì)將通信路徑返回給客戶端。發(fā)送請(qǐng)求時(shí)，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過(guò)一個(gè)服務(wù)器就會(huì)減 1，當(dāng)數(shù)值為 0 時(shí)就停止傳輸。通常不會(huì)使用 TRACE，并且它容易受到 XST 攻擊（Cross-Site Tracing，跨站追蹤）。

36、在瀏覽器中輸入 URL 地址到顯示主頁(yè)的過(guò)程？

• 1 DNS 解析：
  瀏覽器查詢 DNS，獲取域名對(duì)應(yīng)的 IP 地址：具體過(guò)程包括瀏覽器搜索自身的 DNS 緩存、搜索操作系統(tǒng)的 DNS 緩存、讀取本地的 Host 文件和向本地 DNS 服務(wù)器進(jìn)行查詢等。對(duì)于向本地 DNS 服務(wù)器進(jìn)行查詢，如果要查詢的域名包含在本地配置區(qū)域資源中，則返回解析結(jié)果給客戶機(jī)，完成域名解析(此解析具有權(quán)威性)；如果要查詢的域名不由本地 DNS 服務(wù)器區(qū)域解析，但該服務(wù)器已緩存了此網(wǎng)址映射關(guān)系，則調(diào)用這個(gè) IP 地址映射，完成域名解析（此解析不具有權(quán)威性）。如果本地域名服務(wù)器并未緩存該網(wǎng)址映射關(guān)系，那么將根據(jù)其設(shè)置發(fā)起遞歸查詢或者迭代查詢；
• 2 TCP 連接：
  瀏覽器獲得域名對(duì)應(yīng)的 IP 地址以后，瀏覽器向服務(wù)器請(qǐng)求建立鏈接，發(fā)起三次握手；
• 3 發(fā)送 HTTP 請(qǐng)求：
  TCP 連接建立起來(lái)后，瀏覽器向服務(wù)器發(fā)送 HTTP 請(qǐng)求；
• 4 服務(wù)器處理請(qǐng)求并返回 HTTP 報(bào)文：
  服務(wù)器接收到這個(gè)請(qǐng)求，并根據(jù)路徑參數(shù)映射到特定的請(qǐng)求處理器進(jìn)行處理，并將處理結(jié)果及相應(yīng)的視圖返回給瀏覽器；
• 5 瀏覽器解析渲染頁(yè)面：
  瀏覽器解析并渲染視圖，若遇到對(duì) js 文件、css 文件及圖片等靜態(tài)資源的引用，則重復(fù)上述步驟并向服務(wù)器請(qǐng)求這些資源；瀏覽器根據(jù)其請(qǐng)求到的資源、數(shù)據(jù)渲染頁(yè)面，最終向用戶呈現(xiàn)一個(gè)完整的頁(yè)面。
• 6 連接結(jié)束。

37、DNS 的解析過(guò)程？

主機(jī)向本地域名服務(wù)器的查詢一般都是采用遞歸查詢。所謂遞歸查詢就是：如果主機(jī)所詢問(wèn)的本地域名服務(wù)器不知道被查詢的域名的 IP 地址，那么本地域名服務(wù)器就以 DNS 客戶的身份，向根域名服務(wù)器繼續(xù)發(fā)出查詢請(qǐng)求報(bào)文(即替主機(jī)繼續(xù)查詢)，而不是讓主機(jī)自己進(jìn)行下一步查詢。因此，遞歸查詢返回的查詢結(jié)果或者是所要查詢的 IP 地址，或者是報(bào)錯(cuò)，表示無(wú)法查詢到所需的 IP 地址。
本地域名服務(wù)器向根域名服務(wù)器的查詢的迭代查詢。迭代查詢的特點(diǎn)：當(dāng)根域名服務(wù)器收到本地域名服務(wù)器發(fā)出的迭代查詢請(qǐng)求報(bào)文時(shí)，要么給出所要查詢的 IP 地址，要么告訴本地服務(wù)器：“你下一步應(yīng)當(dāng)向哪一個(gè)域名服務(wù)器進(jìn)行查詢”。然后讓本地服務(wù)器進(jìn)行后續(xù)的查詢。根域名服務(wù)器通常是把自己知道的頂級(jí)域名服務(wù)器的 IP 地址告訴本地域名服務(wù)器，讓本地域名服務(wù)器再向頂級(jí)域名服務(wù)器查詢。頂級(jí)域名服務(wù)器在收到本地域名服務(wù)器的查詢請(qǐng)求后，要么給出所要查詢的 IP 地址，要么告訴本地服務(wù)器下一步應(yīng)當(dāng)向哪一個(gè)權(quán)限域名服務(wù)器進(jìn)行查詢。最后，本地域名服務(wù)器得到了所要解析的 IP 地址或報(bào)錯(cuò)，然后把這個(gè)結(jié)果返回給發(fā)起查詢的主機(jī)。

38、談?wù)勀銓?duì)域名緩存的了解？

為了提高 DNS 查詢效率，并減輕服務(wù)器的負(fù)荷和減少因特網(wǎng)上的 DNS 查詢報(bào)文數(shù)量，在域名服務(wù)器中廣泛使用了高速緩存，用來(lái)存放最近查詢過(guò)的域名以及從何處獲得域名映射信息的記錄。
由于名字到地址的綁定并不經(jīng)常改變，為保持高速緩存中的內(nèi)容正確，域名服務(wù)器應(yīng)為每項(xiàng)內(nèi)容設(shè)置計(jì)時(shí)器并處理超過(guò)合理時(shí)間的項(xiàng)（例如：每個(gè)項(xiàng)目?jī)商欤．?dāng)域名服務(wù)器已從緩存中刪去某項(xiàng)信息后又被請(qǐng)求查詢?cè)擁?xiàng)信息，就必須重新到授權(quán)管理該項(xiàng)的域名服務(wù)器綁定信息。當(dāng)權(quán)限服務(wù)器回答一個(gè)查詢請(qǐng)求時(shí)，在響應(yīng)中都指明綁定有效存在的時(shí)間值。增加此時(shí)間值可減少網(wǎng)絡(luò)開(kāi)銷(xiāo)，而減少此時(shí)間值可提高域名解析的正確性。
不僅在本地域名服務(wù)器中需要高速緩存，在主機(jī)中也需要。許多主機(jī)在啟動(dòng)時(shí)從本地服務(wù)器下載名字和地址的全部數(shù)據(jù)庫(kù)，維護(hù)存放自己最近使用的域名的高速緩存，并且只在從緩存中找不到名字時(shí)才使用域名服務(wù)器。維護(hù)本地域名服務(wù)器數(shù)據(jù)庫(kù)的主機(jī)應(yīng)當(dāng)定期地檢查域名服務(wù)器以獲取新的映射信息，而且主機(jī)必須從緩存中刪除無(wú)效的項(xiàng)。由于域名改動(dòng)并不頻繁，大多數(shù)網(wǎng)點(diǎn)不需花精力就能維護(hù)數(shù)據(jù)庫(kù)的一致性。

39、談下你對(duì) HTTP 長(zhǎng)連接和短連接的理解？分別應(yīng)用于哪些場(chǎng)景？

在 HTTP/1.0 中默認(rèn)使用短連接。也就是說(shuō)，客戶端和服務(wù)器每進(jìn)行一次 HTTP 操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。當(dāng)客戶端瀏覽器訪問(wèn)的某個(gè) HTML 或其他類型的 Web 頁(yè)中包含有其他的 Web 資源（如：JavaScript 文件、圖像文件、CSS 文件等），每遇到這樣一個(gè) Web 資源，瀏覽器就會(huì)重新建立一個(gè) HTTP 會(huì)話。
而從 HTTP/1.1 起，默認(rèn)使用長(zhǎng)連接，用以保持連接特性。使用長(zhǎng)連接的 HTTP 協(xié)議，會(huì)在響應(yīng)頭加入這行代碼：Connection:keep-alive
在使用長(zhǎng)連接的情況下，當(dāng)一個(gè)網(wǎng)頁(yè)打開(kāi)完成后，客戶端和服務(wù)器之間用于傳輸 HTTP 數(shù)據(jù)的 TCP 連接不會(huì)關(guān)閉，客戶端再次訪問(wèn)這個(gè)服務(wù)器時(shí)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。
Keep-Alive 不會(huì)永久保持連接，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件（如：Apache）中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長(zhǎng)連接需要客戶端和服務(wù)端都支持長(zhǎng)連接。

40、HTTPS 的工作過(guò)程？

• 1 客戶端發(fā)送自己支持的加密規(guī)則給服務(wù)器，代表告訴服務(wù)器要進(jìn)行連接了；
• 2 服務(wù)器從中選出一套加密算法和 hash 算法以及自己的身份信息（地址等）以證書(shū)的形式發(fā)送給瀏覽器，證書(shū)中包含服務(wù)器信息，加密公鑰，證書(shū)的辦法機(jī)構(gòu)；
• 3 客戶端收到網(wǎng)站的證書(shū)之后要做下面的事情：
  驗(yàn)證證書(shū)的合法性；
  果驗(yàn)證通過(guò)證書(shū)，瀏覽器會(huì)生成一串隨機(jī)數(shù)，并用證書(shū)中的公鑰進(jìn)行加密；
  用約定好的 hash 算法計(jì)算握手消息，然后用生成的密鑰進(jìn)行加密，然后一起發(fā)送給服務(wù)器。
• 4 服務(wù)器接收到客戶端傳送來(lái)的信息，要做下面的事情：
  4.1 用私鑰解析出密碼，用密碼解析握手消息，驗(yàn)證 hash 值是否和瀏覽器發(fā)來(lái)的一致；
  4.2 使用密鑰加密消息；
• 5 如果計(jì)算法 hash 值一致，握手成功。

41、HTTP 和 HTTPS 的區(qū)別？

• 開(kāi)銷(xiāo)：
  HTTPS 協(xié)議需要到 CA 申請(qǐng)證書(shū)，一般免費(fèi)證書(shū)很少，需要交費(fèi)；
• 資源消耗：
  HTTP 是超文本傳輸協(xié)議，信息是明文傳輸，HTTPS 則是具有安全性的 ssl 加密傳輸協(xié)議，需要消耗更多的 CPU 和內(nèi)存資源；
• 端口不同：
  HTTP 和 HTTPS 使用的是完全不同的連接方式，用的端口也不一樣，前者是 80，后者是 443；
• 安全性：
  HTTP 的連接很簡(jiǎn)單，是無(wú)狀態(tài)的；HTTPS 協(xié)議是由 TSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比 HTTP 協(xié)議安全

42、HTTPS 的優(yōu)缺點(diǎn)？

• 優(yōu)點(diǎn)：
  1 使用 HTTPS 協(xié)議可認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器；
  2 HTTPS 協(xié)議是由 SSL + HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比 HTTP 協(xié)議安全，可防止數(shù)據(jù)在傳輸過(guò)程中不被竊取、改變，確保數(shù)據(jù)的完整性；
  3 HTTPS 是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對(duì)安全，但它大幅增加了中間人攻擊的成本。
• 缺點(diǎn)：
  1 HTTPS 協(xié)議握手階段比較費(fèi)時(shí)，會(huì)使頁(yè)面的加載時(shí)間延長(zhǎng)近 50%，增加 10% 到 20% 的耗電；
  2 HTTPS 連接緩存不如 HTTP 高效，會(huì)增加數(shù)據(jù)開(kāi)銷(xiāo)和功耗，甚至已有的安全措施也會(huì)因此而受到影響；
  3 SSL 證書(shū)需要錢(qián)，功能越強(qiáng)大的證書(shū)費(fèi)用越高，個(gè)人網(wǎng)站、小網(wǎng)站沒(méi)有必要一般不會(huì)用；
  4 SSL 證書(shū)通常需要綁定 IP，不能在同一 IP 上綁定多個(gè)域名，IPv4 資源不可能支撐這個(gè)消耗；
  5 HTTPS 協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務(wù)攻擊、服務(wù)器劫持等方面幾乎起不到什么作用。最關(guān)鍵的，SSL 證書(shū)的信用鏈體系并不安全，特別是在某些國(guó)家可以控制 CA 根證書(shū)的情況下，中間人攻擊一樣可行。

43、什么是數(shù)字簽名？

為了避免數(shù)據(jù)在傳輸過(guò)程中被替換，比如黑客修改了你的報(bào)文內(nèi)容，但是你并不知道，所以我們讓發(fā)送端做一個(gè)數(shù)字簽名，把數(shù)據(jù)的摘要消息進(jìn)行一個(gè)加密，比如 MD5，得到一個(gè)簽名，和數(shù)據(jù)一起發(fā)送。然后接收端把數(shù)據(jù)摘要進(jìn)行 MD5 加密，如果和簽名一樣，則說(shuō)明數(shù)據(jù)確實(shí)是真的。

44、什么是數(shù)字證書(shū)？

對(duì)稱加密中，雙方使用公鑰進(jìn)行解密。雖然數(shù)字簽名可以保證數(shù)據(jù)不被替換，但是數(shù)據(jù)是由公鑰加密的，如果公鑰也被替換，則仍然可以偽造數(shù)據(jù)，因?yàn)橛脩舨恢缹?duì)方提供的公鑰其實(shí)是假的。所以為了保證發(fā)送方的公鑰是真的，CA 證書(shū)機(jī)構(gòu)會(huì)負(fù)責(zé)頒發(fā)一個(gè)證書(shū)，里面的公鑰保證是真的，用戶請(qǐng)求服務(wù)器時(shí)，服務(wù)器將證書(shū)發(fā)給用戶，這個(gè)證書(shū)是經(jīng)由系統(tǒng)內(nèi)置證書(shū)的備案的。

45、Cookie 和 Session 有什么區(qū)別？

• 1、由于HTTP協(xié)議是無(wú)狀態(tài)的協(xié)議，所以服務(wù)端需要記錄用戶的狀態(tài)時(shí)，就需要用某種機(jī)制來(lái)識(shí)具體的用戶，這個(gè)機(jī)制就是Session.典型的場(chǎng)景比如購(gòu)物車(chē)。
  當(dāng)你點(diǎn)擊下單按鈕時(shí)，由于HTTP協(xié)議無(wú)狀態(tài)，所以并不知道是哪個(gè)用戶操作的，所以服務(wù)端要為特定的用戶創(chuàng)建了特定的Session，用用于標(biāo)識(shí)這個(gè)用戶，并且跟蹤用戶，這樣才知道購(gòu)物車(chē)?yán)锩嬗袔妆緯?shū)。
  這個(gè)Session是保存在服務(wù)端的，有一個(gè)唯一標(biāo)識(shí)。在服務(wù)端保存Session的方法很多，內(nèi)存、數(shù)據(jù)庫(kù)、文件都有。集群的時(shí)候也要考慮Session的轉(zhuǎn)移，在大型的網(wǎng)站，一般會(huì)有專門(mén)的Session服務(wù)器集群，用來(lái)保存用戶會(huì)話，這個(gè)時(shí)候 Session 信息都是放在內(nèi)存的，使用一些緩存服務(wù)比如Memcached之類的來(lái)放 Session。
• 2、思考一下服務(wù)端如何識(shí)別特定的客戶？這個(gè)時(shí)候Cookie就登場(chǎng)了。每次HTTP請(qǐng)求的時(shí)候，客戶端都會(huì)發(fā)送相應(yīng)的Cookie信息到服務(wù)端。實(shí)際上大多數(shù)的應(yīng)用都是用 Cookie 來(lái)實(shí)現(xiàn)Session跟蹤的，第一次創(chuàng)建Session的時(shí)候，服務(wù)端會(huì)在HTTP協(xié)議中告訴客戶端，需要在 Cookie 里面記錄一個(gè)Session ID，以后每次請(qǐng)求把這個(gè)會(huì)話ID發(fā)送到服務(wù)器，我就知道你是誰(shuí)了。
  有人問(wèn)，如果客戶端的瀏覽器禁用了 Cookie 怎么辦？一般這種情況下，會(huì)使用一種叫做URL重寫(xiě)的技術(shù)來(lái)進(jìn)行會(huì)話跟蹤，即每次HTTP交互，URL后面都會(huì)被附加上一個(gè)諸如 sid=xxxxx 這樣的參數(shù)，服務(wù)端據(jù)此來(lái)識(shí)別用戶。
• 3、Cookie其實(shí)還可以用在一些方便用戶的場(chǎng)景下，設(shè)想你某次登陸過(guò)一個(gè)網(wǎng)站，下次登錄的時(shí)候不想再次輸入賬號(hào)了，怎么辦？這個(gè)信息可以寫(xiě)到Cookie里面，訪問(wèn)網(wǎng)站的時(shí)候，網(wǎng)站頁(yè)面的腳本可以讀取這個(gè)信息，就自動(dòng)幫你把用戶名給填了，能夠方便一下用戶。這也是Cookie名稱的由來(lái)，給用戶的一點(diǎn)甜頭。
• 總結(jié)如下：
  Session是在服務(wù)端保存的一個(gè)數(shù)據(jù)結(jié)構(gòu)，用來(lái)跟蹤用戶的狀態(tài)，這個(gè)數(shù)據(jù)可以保存在集群、數(shù)據(jù)庫(kù)、文件中。
  Cookie是客戶端保存用戶信息的一種機(jī)制，用來(lái)記錄用戶的一些信息，也是實(shí)現(xiàn)Session的一種方式。