035_計算機網絡知識難點歸納

計算機網絡相關知識點整理:

1. OSI，TCP/IP，五層協議的體系結構，以及各層協議?

• OSI：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層
• TCP/IP：網絡接口層、網際層、運輸層、應用層
• 五層協議：物理層、數據鏈路層、網絡層、傳輸層、應用層

	數據單元	設備	協議	功能
物理層	比特 bit	中繼器、集線器、網關	RJ45、CLOCK、IEEE802.3	通過媒介傳輸比特，確定機械及電氣規範
數據鏈路層	幀 frame	網橋、交換機	PPP、FR、HDLC、VLAN、MAC	將比特組裝成幀和點到點的傳遞
網絡層	包 packet	路由器	IP、ICMP、ARP、RARP、IGMP、OSPF、IPX、RIP	負責數據包從源到宿的傳遞和網際互聯
傳輸層	段 segment	進程、端口(socket)	TCP、UDP	提供端到端的可靠報文傳遞和錯誤恢復
會話層	SPDU	服務器驗證用戶登陸、斷點續傳	NFS、SQL、NETBIOS、RPC	建立、管理和終止會話
表示層	PPDU	URL加密、口令加密、圖片編解碼	JPEG、MPEG、ASII	對數據進行翻譯、加密和壓縮
應用層	APDU	–	FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS	允許訪問OSI環境的手段

2. TCP 和 UDP 是什麼?簡述它們有什麼區別?

首先， TCP 和 UDP 都是傳輸層的協議

• TCP：傳輸控制協議，是一種面向連接的可靠傳輸協議。
• UDP：用戶數據報協議，是一種非面向連接的不可靠傳輸協議。，
• 其中，面向連接：傳輸前進行溝通和協商，確保互相可以/願意發送數據；非面向連接：發送數據，收不收無所謂，傳輸數據之前源端和目的端不需要建立連接，不需要維護連接狀態，轉發狀態等。

TCP與UDP區別總結：

1. TCP面向連接；UDP面向無連接的
2. TCP提供可靠的服務；UDP盡最大努力交付，即不保證可靠交付
3. TCP面向字節流，實際上是TCP把數據看成一連串無結構的字節流；UDP是面向報文的
4. TCP連接只能是點對點的；UDP支持一對一，一對多，多對一和多對多的交互通信
5. TCP首部開銷20字節；UDP的首部開銷小，只有8個字節
6. TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道
7. TCP具有擁塞控制；UDP沒有擁塞控制，因此當網絡出現擁塞時不會使源主機的發送速率降低 (這對實時應用很有用，如IP電話，實時視頻會議等)

3. 請描述 TCP 三次握手的過程， 爲什麼要三次握手?

三次握手的過程：

1. 第一次握手：建立連接時，客戶端發送 SYN=J 包到服務器，並且客戶端進入 SYN_SENT 狀態，等待服務器確認(SYN，同步序列編號)
2. 第二次握手：服務器收到 SYN=J 包，會發送 SYN+ACK 包給客戶端，其中，ACK 爲確認包 (ACK=J+1)，同時服務器會發送自己的 SYN=K 包，此時，服務器進入 SYN_RECV狀態
3. 第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK=K+1，此包發送完畢，客戶端和服務器進入ESTABLISHED (TCP連接成功) 狀態，完成三次握手

爲什麼TCP需要三次握手？

總的來說，兩次不可靠，四次不高效。TCP是可靠的傳輸控制協議，三次握手能保證數據可靠傳輸又能提高傳輸效率，而且三次握手可以保證任何一次握手出現問題，都是可以被發現或補救的。

1. 如果是兩次握手：
   在謝希仁著《計算機網絡》第四版中講“三次握手”的目的是“爲了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤”。 現假定出現一種異常情況，即客戶端發出的第一個連接請求報文段並沒有丟失，而是在某些網絡結點長時間滯留了，以致延誤到連接釋放以後的某個時間纔到達服務端。本來這是一個早已失效的報文段。但服務端收到此失效的連接請求報文段後，就誤認爲客戶端又發出一次新的連接請求。於是就向客戶端發出確認報文段，同意建立連接。假定不採用三次握手，那麼只要服務端發出確認後，新的連接便建立了。由於現在客戶端並沒有發出建立連接的請求，因此不會理睬服務端的確認，也不會向服務端發送數據。但服務端卻以爲新的運輸連接已經建立了，並一直等待客戶端發來數據。服務端的許多資源就這樣白白浪費。採用三次握手的辦法可以防止上述現象的發生。例如在剛纔的情況下，客戶端不會向服務端的確認發出確認。服務端由於收不到確認，就知道客戶端並沒有要求建立連接。

2. 如果是4次及以上的握手：
   三次握手之後，客戶端和服務端可以保證正常通信，之後的次數都是徒勞沒有必要，三次握手是可以建立鏈接的最少次數，節約資源使傳輸更加高效。

推薦博文TCP三次握手，爲什麼必須是三次？

4. 請描述 TCP 四次分手的過程, 爲什麼需要四次分手?

四次分手的過程：

1. 客戶端關閉到服務端的連接，所以客戶端發送一個 FIN 包，並且客戶端進入 FIN_WAIT1 狀態
2. 服務器收到FIN 包，會向客戶端發送一個 ACK 包，確認序號爲收到的序號加1。此時，服務端進入 CLOSE_WAIT 狀態，收到 ACK 的客戶端會進入 FIN_WAIT2 狀態
3. 服務器關閉到客戶端的連接，所以服務端發送一個 FIN 包 給客戶端，並且==服務端進入 LAST_ACK ==狀態
4. 客戶端收到該 FIN 包會進入 TIME_WAIT 狀態，並向服務端發回 ACK 報文確認，收到 ACK 後服務端進入 CLOSED 狀態，等待2MSL 時間後無任何響應，客戶端進入 CLOSED 狀態

爲什麼斷開需要四次？
TCP是全雙工模式的，這就意味着，當客戶端發出 FIN 報文段後，只是表示客戶端已經沒有數據要發送了；但是，這個時候客戶端還是可以接受來自服務器的數據；當服務端返回 ACK 報文段時，表示它已經知道客戶端沒有數據要發送了，但是服務端還是可以發送數據到客戶端的；當服務端也發送了 FIN 報文段後，這個時候就表示服務端也沒有數據要發送了，之後彼此就會愉快的中斷這次TCP連接。

5. 四次分手過程中爲什麼等待 2MSL?

首先，什麼是 2MSL?
2MSL 即兩倍的 MSL。
MSL(Maximum Segment Lifetime, 報文最大生存時間)：任何報文在網絡上存在的最長時間，超過這個時間報文將被丟棄。因爲 tcp 報文是 ip 數據報的數據部分，而 ip 頭中有一個 TTL 域，TTL(time to live, 生存時間) 是由源主機設置的初始值並不是存的具體時間，是存儲了一個 ip 數據報可以經過的最大路由數，每經過一個處理他的路由器此值就減1，當此值爲0則數據報將被丟棄，同時發送 ICMP 報文通知源主機。

RFC 793中規定MSL爲2分鐘，實際應用中常用的是30秒，1分鐘和2分鐘等。
TTL 與 MSL 是有關係的但不是簡單的相等的關係，MSL 要大於等於TTL。

然後，爲什麼要等待？爲什麼不直接關閉要進入等待狀態？

1. 保證客戶端發送的 ACK 報文段能夠到達服務器，從而保證tcp連接能夠進行可靠的關閉。
   如果客戶端發動 ACK 後就立刻關閉，如果 ACK 丟失，服務端就會一直處於 LAST_ACK 的狀態，等待超時後再發送關閉請求時，此時的客戶端已經關閉，那麼服務端就無法進行正常的關閉了。
2. 保證此次連接的數據段消失，防止失效的數據段。
   客戶端在發送 ACK 後，再等待 2MSL 時間，可以保證本次連接所產生的數據段從網絡中消失，從而保證關閉連接後不會有還在網絡中滯留的數據段去騷擾服務端

最後，爲什麼是 2MSL？
服務端收到 ACK 後會關閉連接，但是客戶端無法知道自己的ACK是否已經到達服務端，於是開始等待？等待什麼呢？假如ACK沒有到達服務端，服務端會爲 FIN 這個消息超時重傳 timeout retransmit ，即客戶端等待時間足夠，“又”收到FIN消息，也就說明 ACK 沒有到達服務端，於是客戶端再發送 ACK，直到在足夠的時間內沒有收到 FIN，說明 ACK 成功到達。所以這個等待時間至少是：服務端的 timeout + FIN的傳輸時間，爲了保證可靠，採用更加保守的等待時間 2MSL。

6. TCP 粘包是怎麼回事，如何處理？UDP 有粘包嗎？

首先，瞭解 TCP 中的傳輸機制

• 流式套接字
  TCP基於流式套接字，指TCP的數據傳輸跟流動的水一樣沒有界限。
• 緩存機制
  TCP發送數據，並不是應用程序 send 以後就立即發出去，它是先存儲在發送緩衝區中，爲了性能的考慮，可能會等到多個數據包彙總到一起後，操作系統底層再把緩衝區整體發送出去，接收數據也是一樣的。
• 最大傳輸單元
  在網絡傳輸中，有個MTU-最大傳輸單元，是1500個字節，就是說每一次發送最多隻能發送1500個字節，如果要發送超過這個長度的數據包，就需要分包發送。

然後，TCP粘包是什麼？

基於 TCP 在數據傳輸中存在的三種機制，發送方發送的若干包數據到達接收方時可能會粘成了一包，從接收緩衝區來看，後一包數據的頭緊接着前一包數據的尾。

那麼，如何解決粘包？

1. 約定數據包長度，即發送端和接收端約定一樣的發送和接收的數據包長度，這樣可以清晰的獲取到我們需要的數據
2. 使用分隔符，比如 smtp 協議就是在發送時，使用 \r\n 爲分隔符，但如果發送的數據中也有 \r\n ，就容易搞混淆
3. 在每個數據包的開頭利用2個或者4個字節描述整個數據包的長度，接收端可以先接收2個或者4個字節，就可準確的知道真正的數據包是多長，從而正確獲取需要的數據

最後，UDP 有粘包嘛？

• TCP基於流的傳輸，保證可靠傳輸並減少額外的開銷，基於流的傳輸不認爲消息是一條一條的，是無保護消息邊界的。
• UDP是面向消息傳輸的，是有保護消息邊界的，傳輸協議把數據當做一條獨立的消息在網上傳輸，接收方一次只接受一條獨立的信息，所以不存在粘包問題。

7. time_wait 是什麼情況？出現過多的 close_wait 可能是什麼原因？

time_wait 狀態的作用：

1. 保證客戶端發送的 ACK 報文段能夠到達服務器，從而保證tcp連接能夠進行可靠的關閉。
   如果客戶端發動 ACK 後就立刻關閉，如果 ACK 丟失，服務端就會一直處於 LAST_ACK 的狀態，等待超時後再發送關閉請求時，此時的客戶端已經關閉，那麼服務端就無法進行正常的關閉了。
2. 保證此次連接的數據段消失，防止失效的數據段影響新連接。
   客戶端在發送 ACK 後，再等待 2MSL 時間，可以保證本次連接所產生的數據段從網絡中消失，從而保證關閉連接後不會有還在網絡中滯留的數據段去騷擾服務端

大量 time_wait 的原因：
在高併發短連接的TCP服務器上，當服務器處理完請求後立刻主動正常關閉連接，這個場景下會出現大量 socket 處於TIME_WAIT的狀態。如果客戶端的併發量持續很高，此時部分客戶端就會顯示連接不上。

短連接表示“業務處理+傳輸數據的時間 遠遠小於 TIMEWAIT超時的時間”的連接。

大量 close_wait 的原因：
close_wait：關閉 TCP 連接過程中，第 1 次揮手服務器接收客戶端的 FIN 報文段，第 2 次揮手時，服務器發送了 ACK 報文段之後，服務器會進入 close_wait 狀態。
究其原因是：

1. 程序問題：即服務器端的代碼，沒有及時調用 close 函數關閉 socket 連接，也就不會發出 FIN 報文段；或者出現死循環，服務器端的代碼永遠執行不到 close。
2. 客戶機響應太慢或者客戶端的 FIN 消息的超時重傳 timeout 設置過小

8. select, poll, epoll 的區別？邊緣觸發，水平觸發區別？

首先，什麼是 select, poll, epoll？
select，poll，epoll是IO多路複用的機制。
I/O多路複用就通過一種機制，可以監視多個描述符，一旦某個描述符就緒(一般是讀就緒或者寫就緒)，能夠通知程序進行相應的讀寫操作。
IO多路複用適用如下場合：

1. 當客戶處理多個描述字時（一般是交互式輸入和網絡套接口），必須使用I/O複用。
2. 當一個客戶同時處理多個套接口時，而這種情況是可能的，但很少出現。
3. 如果一個TCP服務器既要處理監聽套接口，又要處理已連接套接口，一般也要用到I/O複用。
4. 如果一個服務器即要處理TCP，又要處理UDP，一般要使用I/O複用。
5. 如果一個服務器要處理多個服務或多個協議，一般要使用I/O複用。

I/O多路複用的技術優勢：與多進程和多線程技術相比，系統開銷小，系統不必創建進程/線程，也不必維護這些進程/線程，從而大大減小了系統的開銷。

select，poll，epoll本質上都是同步I/O，因爲他們都需要在讀寫事件就緒後自己負責進行讀寫，也就是說這個讀寫過程是阻塞的，而異步I/O則無需自己負責進行讀寫，異步I/O的實現會負責把數據從內核拷貝到用戶空間。

其次， select, poll, epoll 之間的區別在於：

1. select 機制：准許進程指示內核等待多個事件中的任何一個發生，並通過無差別輪詢在有一個或多個事件發生或經歷一段指定的時間後喚醒(解阻塞)，本質上是通過設置或者檢查存放 fd 標誌位的數據結構來進行下一步處理。
   select 優點：良好的跨平臺性，幾乎所有的平臺都支持
   select 缺點：
   1). 單個進程可監視的套接字數量被限制，即能監聽端口的大小有限。

   一般來說這個數目和系統內存關係很大，32位機默認是1024個。64位機默認是2048.具體數目可以cat /proc/sys/fs/file-max 查看。

   2). 對socket進行掃描時是線性掃描，即採用輪詢的方法，效率較低

   當套接字比較多的時候，每次select()都要通過遍歷FD_SETSIZE個Socket來完成調度,不管哪個Socket是活躍的,都遍歷一遍。這會浪費很多CPU時間。如果能給套接字註冊某個回調函數，當他們活躍時，自動完成相關操作，那就避免了輪詢，這正是epoll與kqueue做的。

   3). 需要維護一個用來存放大量 fd 的數據結構，這樣會使得用戶空間和內核空間在傳遞該結構時複製開銷大

2. poll 機制：與 select 在本質上沒有多大差別，管理多個描述符也是進行輪詢，根據描述符的狀態進行處理。它將用戶傳入的數組拷貝到內核空間，然後查詢每個fd對應的設備狀態，如果設備就緒則在設備等待隊列中加入一項並繼續遍歷，如果遍歷完所有 fd 後沒有發現就緒設備，則掛起當前進程，直到設備就緒或者主動超時，被喚醒後它又要再次遍歷fd。這個過程經歷了多次無謂的遍歷。
   poll 優點：沒有最大連接數限制，原因是基於鏈表來存儲的
   poll 缺點：
   1). 包含大量文件描述符的數組被整體複製於用戶態和內核的地址空間之間，而不論這些文件描述符是否就緒，它的開銷隨着文件描述符數量的增加而線性增大。
   2). poll 是“水平觸發”的，如果報告了 fd 後，沒有被處理，那麼下次poll時會再次報告該 fd。

3. epoll 機制：是在 2.6 內核中提出的，相對於 select 和 poll ，epoll 更加靈活，沒有描述符限制，基於事件通知機制。epoll使用一個文件描述符管理多個描述符，將用戶關係的文件描述符的事件存放到內核的一個事件表中，這樣在用戶空間和內核空間的copy只需一次。
   epoll 優點：
   1). 沒有最大併發連接的限制，(1G的內存上能監聽約10萬個端口)
   2). 效率提升，基於事件通知機制非輪詢的方式，不會隨着 fd 數目的增加效率下降。只有活躍可用的 fd 纔會調用 callback 函數，即epoll最大的優點在於它只管你“活躍”的連接，而跟連接總數無關，因此在實際的網絡環境中，epoll的效率就會遠遠高於select和poll。
   3). 內存拷貝，epoll通過內核和用戶空間共享一塊內存來實現的。利用 mmap() 文件映射內存加速與內核空間的消息傳遞，即 epoll 使用mmap減少複製開銷。

綜上，在選擇select，poll，epoll 時要根據具體的使用場合以及這三種方式的自身特點。

1. 表面上看 epoll 的性能最好，但是在連接數少並且連接都十分活躍的情況下，select 和 poll 的性能可能比 epoll 好，畢竟 epoll 的通知機制需要很多函數回調。
2. select 低效是因爲每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設計改善

水平觸發、邊緣觸發的區別：
如果文件描述符自上次狀態改變後有新的事件發生，此時會觸發通知。在linux的 IO 多路複用中有水平觸發，邊緣觸發兩種模式

水平觸發：處理完成纔會停止通知。當檢測到文件描述符有事件發生並將該事件通知應用程序，如果應用程序不立即對其進行處理，它不會將事件丟棄，它將會一直提示。select，poll就屬於水平觸發。
邊緣觸發：一次通知。在收到一個 IO 事件通知後要儘可能多的執行 IO 操作，因爲如果在一次通知中沒有執行完 IO 那麼就需要等到下一次新的 IO 活動到來才能獲取到就緒的描述符。epoll既可以採用水平觸發，也可以採用邊緣觸發；信號驅動式IO就屬於邊緣觸發。

另一角度理解水平觸發和邊緣觸發的區別：
水平觸發：在高電平(1)或低電平(0)時觸發通知，只要在這兩種狀態就能得到通知。
邊緣觸發：在電平發生變化 (高電平到低電平，或者低電平到高電平) 的時候觸發通知。

【使用場景注意】

1. 在寫 epoll 網絡模型時，如用水平觸發不用擔心數據有沒有讀完因爲下次 epoll 返回時，沒有讀完的 socket 依然會被返回，但是每次 socket 可寫時epoll都會返回，當寫的數據包過大時，一次寫不完，要多次才能寫完，每次寫都會被 epoll 檢測到，因此長期關注 socket 寫事件會無故 cpu 消耗過大甚至導致 cpu 跑滿，所以在水平觸發模式下我們一般不關注socket可寫事件而是通過調用 socket write 或者 send api 函數來寫socket，因此在模式的效率上水平觸發沒有邊緣觸發高
2. 邊緣觸發模式下在讀數據時一定要注意，因爲如果一次可寫事件沒有把數據讀完，在 socket 沒有新的數據可讀時 epoll 就不會返回了，只有在新的數據到來時，我們才能讀取到上次沒有讀完的數據。

9. 簡述一下你瞭解的端口及對應的服務。(至少5 個)

首先，認識端口的分類：

按端口號分佈劃分

1. 知名端口（Well-Known Ports）
   知名端口即衆所周知的端口號，範圍從0到1023，這些端口號一般固定分配給一些服務。比如21端口分配給FTP服務，25端口分配給SMTP（簡單郵件傳輸協議）服務，80端口分配給HTTP服務，135端口分配給RPC（遠程過程調用）服務等等。

2. 動態端口（Dynamic Ports）
   動態端口的範圍從1024到65535，這些端口號一般不固定分配給某個服務，也就是說許多服務都可以使用這些端口。只要運行的程序向系統提出訪問網絡的申請，那麼系統就可以從這些端口號中分配一個供該程序使用。在關閉程序進程後，就會釋放所佔用的端口號。

其次，如何查看端口？

netstat -an
'''
	-a 表示顯示所有活動的TCP連接以及計算機監聽的TCP和UDP端口。

　　-e 表示顯示以太網發送和接收的字節數、數據包數等。

　　-n 表示只以數字形式顯示所有活動的TCP連接的地址和端口號。

　　-o 表示顯示活動的TCP連接幷包括每個連接的進程ID（PID）。

　　-s 表示按協議顯示各種連接的統計信息，包括端口號。
'''

最後，常見的端口及對應服務有：

1. 21端口：FTP(File Transfer Protocol，文件傳輸協議)服務
2. 22端口：SSH(Secure SHell)，使用SSH將所有傳輸的數據進行加密
3. 23端口：Telnet(遠程登錄)服務，是Internet上普遍採用的登錄和仿真程序。
4. 25端口：SMTP(Simple Mail Transfer Protocol，簡單郵件傳輸協議)服務，主要用於發送郵件，如今絕大多數郵件服務器都使用該協議。
5. 53端口：DNS(Domain Name Server，域名服務器)服務器所開放，主要用於域名解析，DNS服務在NT系統中使用的最爲廣泛。
6. 67、68端口：分別是爲Bootp服務的Bootstrap Protocol Server（引導程序協議服務端）和Bootstrap Protocol Client（引導程序協議客戶端）開放的端口。
7. 69端口：TFTP服務，是Cisco公司開發的一個簡單文件傳輸協議，類似於FTP。
8. 80端口：HTTP(HyperText Transport Protocol，超文本傳輸協議)，主要用於在WWW(World Wide Web，萬維網)服務上傳輸信息的協議。
9. 109、110端口：POP2(Post Office Protocol Version 2，郵局協議2)服務開放的，POP3(郵件協議3)服務，POP2、POP3都是主要用於接收郵件的。
10. 111端口：SUN公司的RPC（Remote Procedure Call，遠程過程調用）服務所開放的端口，主要用於分佈式系統中不同計算機的內部進程通信，RPC在多種網絡服務中都是很重要的組件。
11. 113端口：主要用於Windows的“Authentication Service”（驗證服務）。
12. 119端口：爲“Network News Transfer Protocol”（網絡新聞組傳輸協議，簡稱NNTP）開放的。
13. 135端口：主要用於使用RPC（Remote Procedure Call，遠程過程調用）協議並提供DCOM（分佈式組件對象模型）服務。
14. 137端口：主要用於“NetBIOS Name Service”（NetBIOS名稱服務）。
15. 139端口：是爲“NetBIOS Session Service”提供的，主要用於提供Windows文件和打印機共享以及Unix中的Samba服務。
16. 143端口：主要是用於“Internet Message Access Protocol”v2（Internet消息訪問協議，簡稱IMAP）。
17. 161端口：用於“Simple Network Management Protocol”（簡單網絡管理協議，簡稱SNMP）。
18. 443端口：即網頁瀏覽端口，主要是用於HTTPS服務，是提供加密和通過安全端口傳輸的另一種HTTP。
19. 554端口：默認情況下用於“Real Time Streaming Protocol”（實時流協議，簡稱RTSP）。
20. 1024端口：一般不固定分配給某個服務，在英文中的解釋是“Reserved”（保留）。
21. 1080端口：是Socks代理服務使用的端口，大家平時上網使用的WWW服務使用的是HTTP協議的代理服務。
22. 4000端口：用於大家經常使用的QQ聊天工具的，再細說就是爲QQ客戶端開放的端口，QQ服務端使用的端口是8000。
23. 8080端口：同80端口，是被用於WWW代理服務的，可以實現網頁

10. HTTP 協議是什麼?工作原理是什麼?

首先，HTTP 協議是什麼？
HTTP(HyperText Transfer Protocol, 超文本傳輸協議) 是一種用於分佈式、協作式和超媒體信息系統的應用層協議。HTTP是萬維網的數據通信的基礎。

HTTP是客戶端終端（用戶）和服務器端（網站）請求和應答的標準（TCP）。通過使用網頁瀏覽器、網絡爬蟲或者其它的工具，客戶端發起一個HTTP請求到服務器上指定端口（默認端口爲80）。我們稱這個客戶端爲用戶代理程序（user agent）。應答的服務器上存儲着一些資源，比如HTML文件和圖像。我們稱這個應答服務器爲源服務器（origin server）。在用戶代理和源服務器中間可能存在多個“中間層”，比如代理服務器、網關或者隧道（tunnel）。

儘管TCP/IP協議是互聯網上最流行的應用，HTTP協議中，並沒有規定必須使用它或它支持的層。事實上，HTTP可以在任何互聯網協議上，或其他網絡上實現。HTTP假定其下層協議提供可靠的傳輸。因此，任何能夠提供這種保證的協議都可以被其使用。因此也就是其在TCP/IP協議族使用TCP作爲其傳輸層。

通常，由HTTP客戶端發起一個請求，創建一個到服務器指定端口（默認是80端口）的TCP連接。HTTP服務器則在那個端口監聽客戶端的請求。一旦收到請求，服務器會向客戶端返回一個狀態，比如"HTTP/1.1 200 OK"，以及返回的內容，如請求的文件、錯誤消息、或者其它信息。

然後，HTTP 的工作原理：
HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。HTTP協議採用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據；服務器以一個狀態行作爲響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。

HTTP 請求/響應的一般步驟：

1. 客戶端連接到Web服務器
   一個HTTP客戶端，通常是瀏覽器，與Web服務器的HTTP端口（默認爲80）建立一個TCP套接字連接。

2. 發送HTTP請求
   通過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。

3. 服務器接受請求並返回HTTP響應
   Web服務器解析請求，定位請求資源。服務器將資源複本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。

4. 釋放連接TCP連接
   若connection 模式爲close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接；若connection 模式爲keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求。

5. 客戶端瀏覽器解析HTML內容
   客戶端瀏覽器首先解析狀態行，查看錶明請求是否成功的狀態代碼。然後解析每一個響應頭，響應頭告知以下爲若干字節的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，並在瀏覽器窗口中顯示。

HTTP協議的基本特性：

• 基於TCP/IP協議之上的應用層協議。
• 基於“請求-響應”的模式
  HTTP協議規定，請求從客戶端發出，最後服務器端響應該請求並返回。
• 媒體獨立的
  只要客戶端和服務器知道如何處理的數據內容，任何類型的數據都可以通過HTTP發送。客戶端以及服務器指定使用適合的MIME-type內容類型。
• 無狀態協議
  HTTP協議自身不對請求和響應之間的通信狀態進行保存，不做持久化處理。使用HTTP協議，每當有新的請求發送時，就會有對應的新響應產生。這是爲了更快地處理大量事務，確保協議的可伸縮性，而特意把HTTP協議設計成如此簡單的。但是，隨着Web的不斷髮展，因無狀態而導致業務處理變得棘手的情況增多了。比如，用戶登錄到一家購物網站，即使他跳轉到該站的其他頁面後，也需要能繼續保持登錄狀態。針對這個實例，網站爲了能夠掌握是誰送出的請求，需要保存用戶的狀態。HTTP/1.1雖然是無狀態協議，但爲了實現期望的保持狀態功能,，於是引入了Cookie技術。有了Cookie再用HTTP協議通信，就可以管理狀態了。
• 無連接
  無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間，並且可以提高併發性能，不能和每個用戶建立長久的連接，請求一次響應一次，服務端和客戶端就中斷了。但是無連接有兩種方式，早期的http協議是一個請求一個響應之後，直接就斷開了，但是現在的http協議1.1版本不是直接就斷開了，而是等幾秒鐘，這幾秒鐘是等什麼呢，等着用戶有後續的操作，如果用戶在這幾秒鐘之內有新的請求，那麼還是通過之前的連接通道來收發消息，如果過了這幾秒鐘用戶沒有發送新的請求，那麼就會斷開連接，這樣可以提高效率，減少短時間內建立連接的次數，因爲建立連接也是耗時的，默認的好像是3秒中現在，但是這個時間是可以通過咱們後端的代碼來調整的，自己網站根據自己網站用戶的行爲來分析統計出一個最優的等待時間。

11. HTTP 報文結構

客戶端發送一個HTTP請求到服務器的請求消息包括以下格式：請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成

HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文

12. GET 和 POST 請求的區別

根據 HTTP 標準，HTTP 請求可以使用多種請求方法。

• HTTP1.0 定義了三種請求方法： GET、POST 和 HEAD方法。
• HTTP1.1 新增了六種請求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

方法	描述
GET	請求指定的頁面信息，並返回實體主體。
HEAD	類似於 GET 請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
POST	向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST 請求可能會導致新的資源的建立和/或已有資源的修改。
PUT	從客戶端向服務器傳送的數據取代指定的文檔的內容。
DELETE	請求服務器刪除指定的頁面。
CONNECT	HTTP/1.1 協議中預留給能夠將連接改爲管道方式的代理服務器。
OPTIONS	允許客戶端查看服務器的性能。
TRACE	回顯服務器收到的請求，主要用於測試或診斷。
PATCH	是對 PUT 方法的補充，用來對已知資源進行局部更新 。

主要區別在於：

1. GET 是從服務器上獲取數據，POST 是向服務器傳送數據。
2. GET 是不安全的，傳輸過程中會將請求參數放在請求的 URL 中；POST 請求參數在請求體當中，包含在 Content-Type 消息頭裏，指明該消息體的媒體類型和編碼，操作是對用戶不可見的。
3. GET 傳送的數據量小，受 URL 長度的限制；POST 傳輸的數據量較大，被默認爲不受限制（比如請求中包含許多參數或者文件上傳操作等）。
4. GET在瀏覽器回退是無害的；POST 需要再次提交請求。
5. 參數的數據類型，GET 只接受 ASII 編碼；POST無限制。

13. HTTP 常見的狀態碼有哪些? 301，302，404，500，502，504 等

首先，認識狀態碼的分類

HTTP狀態碼共分爲5種類型：

分類	分類描述
1**	信息，服務器收到請求，需要請求者繼續執行操作
2**	成功，操作被成功接收並處理
3**	重定向，需要進一步的操作以完成請求
4**	客戶端錯誤，請求包含語法錯誤或無法完成請求
5**	服務器錯誤，服務器在處理請求的過程中發生了錯誤

常見的狀態碼：

狀態碼	狀態碼英文名稱	中文描述
100	Continue	繼續。客戶端應繼續其請求
101	Switching Protocols	切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議
200	OK	請求成功。一般用於GET與POST請求
301	Moved Permanently	永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。今後任何新的請求都應使用新的URI代替
302	Found	臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI
404	Not Found	服務器無法根據客戶端的請求找到資源（網頁）。通過此代碼，網站設計人員可設置"您所請求的資源無法找到"的個性頁面
500	Internal Server Error	服務器內部錯誤，無法完成請求
502	Bad Gateway	作爲網關或者代理工作的服務器嘗試執行請求時，從遠程服務器接收到了一個無效的響應
503	Service Unavailable	由於超載或系統維護，服務器暫時的無法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中
504	Gateway Time-out	充當網關或代理的服務器，未及時從遠端服務器獲取請求

14. HTTP 與 HTTPS 的區別是什麼?

詳細的介紹博文推薦：https://www.cnblogs.com/shoshana-kong/p/10583760.html
HTTPS：是以安全爲目標的HTTP通道，簡單講是HTTP 的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。

HTTPS 協議的主要作用：

• 一是建立一個信息安全通道，來保證數據傳輸的安全；
• 二是確認網站的真實性。

HTTPS 和 HTTP 的區別主要如下：

1. https 協議需要到 ca 申請證書，一般免費證書較少，因而需要一定費用。

2. http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl 加密傳輸協議。

3. http 和 https 使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。

4. http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

15. 在瀏覽器中輸入www.baidu.com 後執行的全部過程。

IP：邏輯上標記一臺設備；MAC：網卡序列號，標記實際的轉發數據的設備

1. 首先需要 DNS 服務器解析出 www.baidu.com 的 IP 地址
   1). 這是需要知道默認網關的 mac，於是，使用 RAP 協議獲得默認網關的 mac
   2). 組織數據發送給網關，(IP 還是 DNS 服務器的，但是 mac 地址是默認網關的mac)
   3). 默認網關擁有轉發數據的能力，將數據轉發給路由器
   4). 路由器根據自己的路由協議，選擇合適的較快的路徑轉發數據給目的網關
   5). 目的網關(即，DNS服務器所在的網關) 把數據轉發給 DNS 服務器
   6). DNS 服務器解析出 www.baidu.com 域名對應的 IP地址，並將其原路返回給請求的 client

2. 得到 www.baidu.com 對應的 IP 後，進行 TCP 三次握手建立連接
   1). 第一次握手：建立連接時，客戶端發送 SYN=J 包到服務器，並且客戶端進入 SYN_SENT 狀態，等待服務器確認(SYN，同步序列編號)
   2). 第二次握手：服務器收到 SYN=J 包，會發送 SYN+ACK 包給客戶端，其中，ACK 爲確認包 (ACK=J+1)，同時服務器會發送自己的 SYN=K 包，此時，服務器進入 SYN_RECV狀態
   3). 第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK=K+1，此包發送完畢，客戶端和服務器進入ESTABLISHED (TCP連接成功) 狀態，完成三次握手

3. 基於 HTTP 協議實現與 web 服務器的數據通信。
   1). 瀏覽器發送一個Request請求去獲取 http://www.baidu.com 的html文件。
   2). web 服務器接收到數據請求後，查詢自己的服務器得到相應的響應，原路返回給瀏覽器，即服務器把 Response 文件對象發送回給瀏覽器。
   3). 瀏覽器分析 Response 中的 HTML，發現其中引用了很多其他文件，比如Images文件，CSS文件，JS文件。瀏覽器會自動再次發送 Request 去獲取圖片，CSS文件，或者JS文件。
   4). 當所有的文件都下載成功後，網頁會根據HTML語法結構，完整的顯示出來了。

4. 四次揮手，釋放 TCP 連接
   1). 客戶端關閉到服務端的連接，所以客戶端發送一個 FIN 包，並且客戶端進入FIN_WAIT1 狀態
   2). 服務器收到FIN 包，會向客戶端發送一個 ACK 包，確認序號爲收到的序號加1。此時，服務端進入 CLOSE_WAIT 狀態，收到 ACK 的客戶端會進入 FIN_WAIT2 狀態
   3). 服務器關閉到客戶端的連接，所以服務端發送一個 FIN 包 給客戶端，並且 服務端進入 LAST_ACK 狀態
   4). 客戶端收到該 FIN 包會進入 TIME_WAIT 狀態，並向服務端發回 ACK 報文確認，收到 ACK 後服務端進入 CLOSED 狀態，等待2MSL 時間後無任何響應，客戶端進入 CLOSED 狀態

16. 常用加密算法及原理

常見的密鑰加密算法類型大體可以分爲三類：對稱加密、非對稱加密、單向加密。

1. 對稱加密算法
   對稱加密算法採用單密鑰加密，在通信過程中，數據發送方將原始數據分割成固定大小的塊，經過密鑰和加密算法逐個加密後，發送給接收方；接收方收到加密後的報文後，結合密鑰和解密算法解密組合後得出原始數據。由於加解密算法是公開的，因此在這過程中，密鑰的安全傳遞就成爲了至關重要的事了。
   優點： 算法公開、計算量小、加密速度和效率高
   缺點： 密鑰單一、密鑰管理困難等

常見的對稱加密算法有：
DES：分組式加密算法，以64位爲分組對數據加密，加解密使用同一個算法。
3DES：三重數據加密算法，對每個數據塊應用三次 DES 加密算法。
AES：高級加密標準算法，是美國聯邦政府採用的一種區塊加密標準，用於替代原先的 DES，目前已被廣泛應用。
Blowfish：Blowfish算法是一個64位分組及可變密鑰長度的對稱密鑰分組密碼算法，可用來加密64比特長度的字符串。

2. 非對稱加密算法
   非對稱加密算法採用公鑰和私鑰兩種不同的密碼來進行加解密。公鑰和私鑰是成對存在，公鑰是從私鑰中提取產生公開給所有人的，如果使用公鑰對數據進行加密，那麼只有對應的私鑰才能解密，反之亦然。
   優點：安全性高、算法強度不復雜
   缺點：加解密耗時長、速度慢，只適合對少量數據進行加密，

其常見算法包括：
RSA：RSA算法基於一個十分簡單的數論事實：將兩個大素數相乘十分容易，但那時想要對其乘積進行因式分解卻極其困難，因此可以將乘積公開作爲加密密鑰，可用於加密，也能用於簽名。
DSA：數字簽名算法，僅能用於簽名，不能用於加解密。
DSS：數字簽名標準，技能用於簽名，也可以用於加解密。
ELGamal：利用離散對數的原理對數據進行加解密或數據簽名，其速度是最慢的。

3. 單向加密
   單向加密算法常用於提取數據指紋，驗證數據的完整性。發送者將明文通過單向加密算法加密生成定長的密文串，然後傳遞給接收方。接收方在收到加密的報文後進行解密，將解密獲取到的明文使用相同的單向加密算法進行加密，得出加密後的密文串。隨後將之與發送者發送過來的密文串進行對比，若發送前和發送後的密文串相一致，則說明傳輸過程中數據沒有損壞；若不一致，說明傳輸過程中數據丟失了。單向加密算法只能用於對數據的加密，無法被解密，其特點爲定長輸出、雪崩效應。

常見的算法包括：MD5、sha1、sha224等，其常見用途包括：數字摘要、數字簽名等等。