面試專題之網絡編程

題目

1. TCP 三次握手、四次揮手流程？三次握手作用？爲什麼三次，爲什麼四次？
2. TCP 和 UDP 區別，優缺點？有 TCP 爲什麼還要有 UDP？舉幾個實際應用的例子
3. TCP 粘包和拆包問題有了解嗎？
4. TCP 是怎樣保持連接的？怎樣識別不同請求的？
5. 用 Java 的套接字編程實現一個多線程的回顯（echo）服務器。
6. socket 選項 TCP NO DELAY 是指什麼？
7. Http請求的過程與原理
8. 關於CP連接可靠通信的幾個問題
9. tcp是如何保證安全的
10. https和http的區別？
11. get/post區別？
12. cookie和session的區別
13. xss攻擊和ddos？
14. 你知道的協議有哪些，在哪個層，有什麼用？
15. 常見狀態碼及原因短語

答案

1. TCP 三次握手、四次揮手流程？三次握手作用？爲什麼三次，爲什麼四次？

三次握手：
剛開始客戶端處於 closed 的狀態，服務端處於 listen 狀態。然後
第一次握手：客戶端給服務端發一個 SYN 報文，並指明客戶端的初始化序列號 ISN（c）。此時客戶端處於 SYN_Send 狀態。
第二次握手：服務器收到客戶端的 SYN 報文之後，會以自己的 SYN 報文作爲應答，並且也是指定了自己的初始化序列號 ISN(s)，同時會把客戶端的 ISN + 1 作爲 ACK 的值，表示自己已經收到了客戶端的 SYN，此時服務器處於 SYN_REVD 的狀態。
第三次握手：客戶端收到 SYN 報文之後，會發送一個 ACK 報文，當然，也是一樣把服務器的 ISN + 1 作爲 ACK 的值，表示已經收到了服務端的 SYN 報文，此時客戶端處於 establised 狀態。

服務器收到 ACK 報文之後，也處於 establised 狀態，此時，雙方以建立起了鏈接。

四次揮手：
剛開始雙方都處於 establised 狀態，假如是客戶端先發起關閉請求，則
第一次揮手：客戶端發送一個 FIN 報文，報文中會指定一個序列號。此時客戶端處於FIN_WAIT1狀態。
第二次握手：服務端收到 FIN 之後，會發送 ACK 報文，且把客戶端的序列號值 + 1 作爲 ACK 報文的序列號值，表明已經收到客戶端的報文了，此時服務端處於 CLOSE_WAIT狀態。
第三次揮手：如果服務端也想斷開連接了，和客戶端的第一次揮手一樣，發給 FIN 報文，且指定一個序列號。此時服務端處於 LAST_ACK 的狀態。
第四次揮手：客戶端收到 FIN 之後，一樣發送一個 ACK 報文作爲應答，且把服務端的序列號值 + 1 作爲自己 ACK 報文的序列號值，此時客戶端處於 TIME_WAIT 狀態。需要過一陣子以確保服務端收到自己的 ACK 報文之後纔會進入 CLOSED 狀態

服務端收到 ACK 報文之後，就處於關閉連接了，處於 CLOSED 狀態。

作用：
簡要回答：作用是爲了確認雙方的接收與發送能力是否正常。
詳細回答：
a. 確認雙方的接受能力、發送能力是否正常。
b. 指定自己的初始化序列號，爲後面的可靠傳送做準備。
c. 如果是 https 協議的話，三次握手這個過程，還會進行數字證書的驗證以及加密密鑰的生成到。

爲什麼是連接和關閉握手是三次和四次？
因爲當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，“你發的FIN報文我收到了”。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。

推薦閱讀：面試中被問到三次握手四次揮手應該怎麼回答？
TCP的三次握手與四次揮手理解及面試題（很全面）

2. TCP 和 UDP 區別，優缺點？有 TCP 爲什麼還要有 UDP？舉幾個實際應用的例子

簡要回答：
TCP保證數據安全，以流的形式傳輸，一對一雙全工，能保證數據順序
UDP不保證數據安全，以數據報的形式傳輸，一對多，不保證數據順序

詳細回答：
協議層面
(1) TCP是面向連接的協議，有確認重傳機制，流量控制機制等；而UDP是非面向連接的協議，盡力而爲的傳送數據，重傳由上層協議來控制，也可以使用connect()來控制。
(2)從頭部結構來說，TCP因爲有選項部分，所以有首部長度字段；而UDP沒有選項部分，所以不需要首部長度字段。
(3)TCP的checksum部分是必需的；UDP的選項部分是可選的，不填充的話默認爲全零。
(4)TCP避免分段，因爲有重傳機制本來就浪費了一些帶寬，一旦出現分段，那麼重傳會大量增加，將會浪費大量帶寬並且會嚴重降低傳輸效率；而UDP則不關心分不分段，且因爲UDP的頭部小（只有8字節，而TCP頭部最小也得20字節），故可以攜帶更多的數據。
(5)TCP是基於數據流傳輸的，所以應用程序產生的全體數據與真正發送的單個IP數據報沒有什麼聯繫；而UDP是面向數據報的傳輸層協議，進程的每個操作產生都正好產生一個UDP數據報，並組裝成一個IP數據報發送。
應用層面
（1）先說一下TCP的優缺點。優點：TCP是可靠的連接，由於有基本的重傳確認機制，可以保證把一個數據塊完完整整的從A傳到B；缺點也是因優點而生，因爲有三次握手，所以會傳輸更多的包，浪費一些帶寬；因爲需要可靠地連接進行通信，則需要雙方都必須持續在線，所以在通信過程中server需要維持非常大的併發連接，浪費了系統資源，甚至會出現宕機；再者就是因爲有重傳確認，則會浪費一部分的帶寬，且在不好的網絡中，會因爲不斷地連接斷開連接，嚴重降低了傳輸效率。
（2）相對於TCP來說，UDP是非面向連接的不可靠的協議，其優點也因爲缺點而生。首先，因爲沒有三次握手，所以會起步比較快，延時小；另外，由於不需要雙方持續在線，所以server不用維護巨量的併發連接，節省了系統資源；三，因爲沒有重傳確認，雖然到達的數據可能會有所缺失，但在不影響使用的情況下，能更高效的利用網絡帶寬。

爲什麼還要有udp:
TCP適合實時性要求不高，但要求內容要完整傳輸的應用。相比而言，UDP由於無連接、無重傳確認，所以傳輸效率高、延時小，適合實時性要求高的應用，如遊戲服務器，音頻，視頻等；另外，由於不用維持大的併發量，所以適合巨量服務的server，加上合適的時間控制，可以用來設計更大的併發服務器；再者就是，UDP可以更高效的利用網絡帶寬。

例子：
QQ，在建立連接階段，使用的是面向連接的TCP協議，通過三次握手來完成；然後，在文字數據傳輸階段，使用的是UDP協議，但需要中間服務器轉發（估計是使用了connect()的UDP，QQ離線發送/接收數據的基礎);
然後，音視頻數據的發送一定是使用的UDP，因爲一般的客戶可以容忍稍微模糊(略有缺失的數據塊）的聲音或視頻，但估計不會接受一會斷開一會連接（因爲TCP容易斷線）的音視頻；
而文件傳輸則使用了P2P的協議，當前大多P2P使用的UTP協議也是基於UDP的，因爲使用TCP的話會浪費大量的帶寬。

3. TCP 粘包和拆包問題有了解嗎？
   概念：
   Tcp是個“流協議”，所謂流，就是沒有界限的一連串數據，沒有界限。TCP底層不瞭解業務數據的含義，它會根據TCP緩衝區的實際情況進行包的劃分，所以業務上認爲，一個完整的包可能被TCP拆分爲多個包進行發送，也可能把多個小包封裝成一個大的數據包進行發送，這就是所謂的TCP粘包和拆包問題。
   
   產生原因：
   （1）應用程序write寫入的字節大小大於套接口緩衝區的大小
   （2）進行MSS大小的TCP分段
   （3）以太網幀的payload大於MTU進行IP分片
   
   解決方案：
   （1）消息定長，例如每個報文固定200字節，如果不夠，空位補空格
   （2）在包尾增加回車換行符進行分割，如FTP協議
   （3）將消息分爲消息頭和消息體，消息頭中包含消息的長度，字段等信息
   （4）更復雜的應用層協議

推薦閱讀：
TCP粘包和拆包

還有本人所寫的netty高級，在第二部分中通過代碼實驗拆包和粘包問題，還有拆包的解決方案

4. TCP 是怎樣保持連接的？怎樣識別不同請求的？
   TCP長連接保持：KeepAlive。TCP協議的實現裏有一個KeepAlive機制，自動檢測能否和對方連通並保持連接。

TCP識別不同的請求：每個連接建立時，都會保存一個唯一的套接字，有了這個套接字，你就知道對方的IP地址、端口號等信息。這樣，通過這個套接字，就可以向指定方發送信息了。

5. 用 Java 的套接字編程實現一個多線程的回顯（echo）服務器。
   Java - 用Java的套接字編程實現一個多線程的回顯（echo）服務器。

6. socket 選項 TCP NO DELAY 是指什麼？
   詳解Socket編程—TCP_NODELAY選項

7. Http請求的過程與原理
   （1）DNS解析，先從瀏覽器緩存、內存緩存、host文件、DNS服務器一步步把url解析成ip地址
   （2）拿到ip地址之後如果是自己網段的，一般路由器裏都有對應的mac地址，可以直接獲得然後三次握手建立TCP連接，如果不是自己網段的，還需要發到網關，由arp協議得到mac地址。因爲七層模型都是上層依賴下層，你想傳輸肯定得把網絡和數據鏈路層搞定。
   （3）建立起TCP連接後就可以發送HTTP請求了，這個請求到了服務端可能會有負載均衡、重定向，
   （4）處理完請求後把請求返回，由瀏覽器解析數據時發現還有一些靜態資源比如CSS JS或圖片，又會發起另外的請求，這就是後話了。
   （5）處理完成後B/S架構不像C/S，一般都是短連接，四次揮手就關閉了
   Http請求的過程與原理

8. 關於CP連接可靠通信的幾個問題

在可靠的通訊連接方便： 採用三次我握手的機制

（1）TCP是怎麼保證沒有比特差錯的？
爲了保證接受的報文段是沒有比特差錯的，TCP中引入了這三個機制：
①差錯檢測：也就是引入校驗和。在TCP的首部中有一個佔據16爲的空間用來放置校驗和的結果。在源主機的運輸層開始接受到一個從應用進程傳下來的數據的時候，會將他封裝成一個報文段，加上至少20字節的首部。同時會將這個報文段首部和數據還有僞首部部分一起根據取反碼和的形式計算出校驗和添加到首部中。傳輸到目的主機的運輸層之後，會計算這個通過這個校驗和檢查是否存在比特差錯。
②控制消息：當檢測到發生比特差錯之後要對發送發進行信息的反饋使得能夠根據返回決定是否進行重傳。一般理論上會有兩種返回一種是肯定的反饋ACK，在TCP中反饋信息是接收到的分許中最後一個字節序號的下一位。一種是否定反饋，但是爲了減少網絡中的注入分組的數量減少負擔取而代之的是通過發送上一個分組的確認信息表明當下這個分組沒有正確的接收。
③重傳：如果接收方接收到的是一個換掉的ACK或者上一個分組的確認之後意味着要再發一遍這個分許。怎麼發後面將分析到。

（2）TCP是怎麼保證重傳的？
發送發重傳之後，接收方值怎麼知道這個分組是重傳的分許，或者說接收方怎麼知道我是不是已經接受了這個分組的？引入了序列化的機制。由於TCP是面向字節流的協議，所以會爲每一個字節編制一個序號。同時在TCP首部中也會有這個序號字段。但是由於一個分組中包含了多個字節，所以說這個TCP首部中的序號是分組中發送多個字節的第一個字節的序號值。

（3）TCP是怎麼處理分組丟棄的問題的？
以上這幾個問題是基於分組沒有丟棄但是僅僅發生比特差錯的時候。如果發生比特差錯怎麼辦。協議張引入了定時器這個機制。也就是說在某一時刻設置一個定時器，只要在定時器設置的時間內沒有收到對應分組的確認信息，那麼就會重傳對應的一個或者幾個分組。

（5）TCP是如何提高傳輸性能的？
在TCP協議中爲了提高傳輸性能是不可能一次只能發送一個分組介紹到這個分組確認之後在發送下一個分組的，因爲這樣對於信道的利用效率會大大減少，所以爲了提高信道的利用率一般一次發送多個分組，並且將這幾個分組爲單位開始設置定時器。
同時也引入了快速重傳的機制。

（6）TCP爲什麼引入接受緩存這個數據結構？
如果沒有接受緩存的話，或者說只有一個緩存的話，爲了保證接受的數據是按順序傳輸的，所以如果位於x序號之後的序號分組先到達目的主機的運輸層的話必然丟棄，這樣的話將在重傳上花費很大的開銷，所以一般如果有過大的序號達到接收端，那麼會按照序號緩存起來等待之前的序號分許到達，然後一併交付到應用進程。

推薦閱讀 TCP是如何保證可靠數據傳輸的？

9. tcp是如何保證安全的
   （1）應用數據被分割成 TCP 認爲最適合發送的數據塊。
   （2）TCP 給發送的每一個包進行編號，接收方對數據包進行排序，把有序數據傳送給應用層。
   （3）校驗和： TCP 將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP 將丟棄這個報文段和不確認收到此報文段。
   （4）TCP 的接收端會丟棄重複的數據。
   （5）流量控制： TCP 連接的每一方都有固定大小的緩衝空間，TCP的接收端只允許發送端發送接收端緩衝區能接納的數據。當接收方來不及處理髮送方的數據，能提示發送方降低發送的速率，防止包丟失。TCP 使用的流量控制協議是可變大小的滑動窗口協議。 （TCP 利用滑動窗口實現流量控制）
   （6）擁塞控制： 當網絡擁塞時，減少數據的發送。
   （7）停止等待協議: 也是爲了實現可靠傳輸的，它的基本原理就是每發完一個分組就- 停止發送，等待對方確認。在收到確認後再發下一個分組。 超時重傳： 當 TCP 發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。

推薦閱讀 TCP 協議如何保證可靠傳輸

10. https和http的區別？
    （1）https 協議需要到 ca 申請證書，一般免費證書較少，因而需要一定費用。
    （2）http 是超文本傳輸協議，信息是明文傳輸，無狀態，連接較爲簡單
    https 則是具有安全性的，在TCP/IP協議上封裝了一層TCL/SSL加密傳輸協議，以數字證書的形式來保證數據安全（將用戶數據hash後由公鑰加密成密文，拿到報文後解密密文，並再次將數據hash，比較數據是否相同，第一次傳輸用RSA得到對稱加密的祕鑰，之後都用對稱加密）
    （3）http 和 https 使用的是完全不同的連接方式，用的端口也不一樣，前者是 80，後者是 443。

11. get/post區別？
    本質上是無區別的，
    在瀏覽器端，get一般由url調用，順帶一提url的限制也是瀏覽器的原因，事實上http標準協議對url的長度沒有限制，而post一般由表單調用
    在restful規範中，get被認爲是冪等的，用來請求數據，而post不冪等，用來實現資源的創建
    推薦閱讀GET 和 POST 到底有什麼區別？
    

12. cookie和session的區別
    cookie保存在瀏覽器端，一般有4BK的大小限制，cookie會有cros的安全問題，簡單來說就是別的噁心請求拿到了cookie之後每次請求都帶上，解決方法是用token或者直接禁用cookie，使用token可以讓特定的請求帶上而不是每次請求都帶上。
    session保存在服務器端，需要用url或者cookie請求sessionid拿到

13. xss攻擊和ddos？
    xss其原理是攻擊者向有XSS漏洞的網站中輸入惡意的 HTML 代碼，當用戶瀏覽該網站時，這段 HTML 代碼會自動執行
    ddos 簡單來說就是大量請求去攻擊一個公用接口，使服務器負載上升
    什麼是 DDoS 攻擊？

14. 你知道的協議有哪些，在哪個層，有什麼用？
    簡單挑幾個記吧。。 TCP IP ARP RAPR PPPOE SSL HTTP FTP SMTP
    

15. 常見狀態碼及原因短語
    1XX請求成功，正在處理
    2XX請求成功，已經處理
    3XX 重定向
    301永久重定向
    302臨時重定向
    4XX
    400 請求語法錯誤
    403 服務被拒絕
    404頁面不存在
    5XX
    500服務器內部錯誤（報錯了）
    502 服務不可用