TCP與HTTP面試題
- http1.0和http1.1有什麼區別。
- http基於tcp/ip協議，創建tcp鏈接需要經過三次握手後才能獲取資源，如果每次請求都要這樣創建對性能會有影響,此時就需要長連接來保持，減少創建成本。http1.0需要使用keep-alive參數主動告知服務器創建長連接，兒http1.1默認支持長連接：Connctiong:keep-alive
- http1.1 增加了host域：http1.0認爲每臺服務器都綁定一個唯一的ip地址，因此請求消息url中並沒有傳遞主機名。隨着虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機，並且他們共享一個ip地址，http1.1請求中如果沒有host頭域會報告錯誤：400 Bad Request
- http1.1可以只發送header信息,服務端正常返回100，異常401.接收到100狀態時，客戶端可以繼續發送body體，這樣可以節約寬帶，減少無效請求，其也是文件斷點續傳的基礎。
- http1.1 增加24個錯誤狀態響應碼。如：409 表示請求的資源與該資源當前的狀態衝突。410 表示服務器上資源被刪除。
- TCP三次握手和四次揮手的流程，爲什麼斷開連接要4次,如果握手只有兩次，會出現什麼。
- 三次握手：
- 第一次握手：客戶端發送連接請求到服務器，此時客戶端進入同步已發送狀態(SYN-SEND)
- 第二次握手：服務器收到連接請求報文，並向客戶端發送確認，服務端進入同步收到狀態(SYN-RCVD)
- 第三次握手：客戶端收到服務端的確認，再次向服務端給出確認。此時服務端可客戶端都進入 已建立連接狀態(ESTABLISHED)
- 如果握手只有兩次:如果缺少第三次握手，服務端不接收客戶端的再次確認信息，容易導致客戶端和服務端狀態不一致。如：客戶端發送的請求由於某種原因延遲發送的服務端，客戶端在超時情況下重試發送請求，忽略延遲請求。當該延遲請求到達服務端後，服務端做確認動作，這是客戶端因爲已經忽略該請求，到時服務端在該次連接上的無效等待，從而造成資源的浪費。
- 四次揮手：
- 第一次揮手：客戶端發出連接釋放請求，此時處於 等待1狀態(FIN-WAIT-1)
- 第二次揮手：服務端發出確認，並進入 關閉等待狀態(CLOSE-WAIT)，此時客戶端收到後，進入等待2狀態(FIN-WAIT-2)
- 第三次揮手：服務端發出連接釋放動作，進入 確認狀態（LAST-ACK）
- 第四次揮手：客戶端收到釋放動作進入 等待狀態(TIMIE-WAIT)，服務端收到進入 關閉狀態(CLOSED),客戶端在等待一段時間後也進入關閉狀態（2MSL）
- 爲什麼斷開連接要4次:tcp協議是一種面向連接的、可靠的、基於字節流的運輸層通信協議。兩個連接斷開是雙向的，A向B斷開，B確認。此時B依然可以通信A，這時就是B向A斷開，A確認。
- TIME_WAIT和CLOSE_WAIT的區別。
- TIME_WAIT是主動關閉連接時形成的，等待2MSL時間，約4分鐘，防止最後一個釋放確認動作丟失。
- CLASE_WAIT是被動關閉連接形成的。服務端收到客戶端的釋放連接請求並進行確認胡進入CLOSE_WAIT狀態。如果服務器端不執行close，就不能由CLOSE_WAIT遷移到LAST_ACK.
- 說說你知道的幾種HTTP響應碼，比如200, 302, 404。
- 200：請求成功
- 302：臨時性重定向
- 404：請求資源服務器未找到
- 500：服務器遇到未知情況
- 502：請求未完成。服務器從上游服務器收到一個無效的響應。
- 100：服務器收到部分請求。
- 當你用瀏覽器打開一個鏈接（如：http://www.javastack.cn）的時候，計算機做了哪些工作步驟。
- dns解析–>端口分析–>tcp請求–>服務器處理請求–>服務器響應–>瀏覽器解析—>連接關閉
- TCP/IP如何保證可靠性，說說TCP頭的結構。
- TCP/IP如何保證可靠性
- 校驗和：發送方在發送數據之前計算校驗和並填充，接收方收到數據後，對數據以同樣的方式進行計算求出校驗和並對比
- 確認應答與序列號：tcp傳輸過程中，每次接收方收到數據後，都會對傳輸方進行確認癮大。也就是放鬆ACK報文。這個ACK報文當中帶有對應的確認序列號，告訴發送方，接收到了哪些數據，下一次的數據從哪裏發。
- 超時重傳：發送方在發送完數據後等待一段時間，時間到後沒有收到報文信息，那麼對剛纔發送的數據進行重新發送。等待的時長是動態計算的，例如：linux , 初始超時500ms，後續等待已2的指數增長：2 * 500、4 * 500
- 連接管理：三次握手、四次揮手保證連接可靠
- 流量控制：接收端會在tcp協議的報文頭信息當中，指定接收數據大小，客戶端根據該配置發送指定數量的數據。
- 擁塞控制：tcp引入慢啓動的機制，在開始發送數據時，先發送少量的數據探路。探清當前的網絡狀態，再決定多大的速度傳輸
- TCP頭的結構
- 16位端口號：告知主機該報文段來自哪裏(源端口)，以及傳給那個上層協議或應用程序(目的端口)
- 32位序列號：一次tcp通信過程中某一個傳輸方向上的字節流的問個字節的編號。
- 32位確認好：用作對另一方發送來的tcp報文段的響應。
- 4位頭部長度：標識該tcp頭部有杜少個32bit字
- 6位標誌位：配置標誌位指定功能
- 16位窗口大小：流量控制
- 16位校驗和：校驗和
- 16位緊急指針
- 16位選項
- 如何避免瀏覽器緩存
- Cache-Control/Pragma 設置 no-cache 告知不緩存
- 過期時間設置爲0： Expires = 0
- 對請求資源你添加版本號 例如：xx.js?version=1
- 如何理解HTTP協議的無狀態性。
- 服務端對於客戶端每次發送的請求都認爲它是一個新的請求，上一次會話和下一次會話沒有聯繫；http協議這種特性優點在於解放了服務器，每次請求點到爲止，不會造成不必要連接佔用，缺點在於每次請求會傳輸大量重複的內容信息。
- 簡述Http請求get和post的區別以及數據包格式。
- get/post區別
- 在客戶端，Get方式在通過URL提交數據，數據在URL中可以看到；POST方式，數據放置在body體內提交。
- 在HTTP規範中，沒有對URL的長度和傳輸的數據大小進行限制。但是在實際開發過程中，對於GET，特定的瀏覽器和服務器對URL的長度有限制。對於POST，由於不是URL傳值，理論上是不會受限制的，但是實際上各個服務器會規定對POST提交數據大小進行限制
- 安全性。使用 Get 的時候，參數會顯示在地址欄上，而 Post 不會。所以，如果這些數據是中文數據而且是非敏感數據，那麼使用 get；如果用戶輸入的數據不是中文字符而且包含敏感數據，那麼還是使用 post爲好。
- GET在瀏覽器回退時是無害的，而POST會再次提交請求
- GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。
- 數據包：Get產生一個TCP數據包；Post產生兩個TCP數據包。
- 對於GET方式的請求，瀏覽器會把http header和data一併發送出去，服務器響應200（返回數據）；
- 對於POST，瀏覽器先發送header，服務器響應100（continue），然後再發送data，服務器響應200（返回數據）；
- HTTP有哪些method
- get: 請求制定頁面信息，並返回實體
- head: 功能類似於get請求，不過返回的響應中沒有具體內容，用於獲取報頭
- post: 想制定資源體驕傲數據進行處理請求
- put: 從客戶端向服務起傳送數據
- delete: 請求刪除
- options: 客戶端查看服務起性能
- link: 請求服務起建立鏈接關係
- 。。。。。等等
- 簡述HTTP請求的報文格式。
- http 請求報文由請求行、請求頭、請求包體 4個部分組成。
- 請求行：由3部分組成，分別爲：請求方法、URL以及協議版本，之間由空格分隔
- 請求頭部：請求頭部爲請求報文添加了一些附加信息，由“名/值”對組成，每行一對，名和值之間使用冒號分隔。如：ua、host
- 請求包體：可選部分，get請求可無。
- HTTP的長連接是什麼意思。
- 而從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭加入這行代碼：Connection:keep-alive.在使用長連接的情況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。
- HTTPS的加密方式是什麼，講講整個加密解密流程。
- 加密方式：非對稱加密和對稱加密協調配合。
- 整個流程大概：
- 客戶端發起https請求
- 服務端配置證書
- 傳送證書：這個證書其實是公鑰，包含了很多信息，如證書的頒發機構，過期時間。
- 客戶端解析證書：客戶端的TLS負責解析證書，驗證公鑰的有效性。驗證後生成一個隨機值，用證書對隨機值進行加密
- 傳送加密信息
- 服務端解密信息：服務端用私鑰解密，得到客戶端的隨機值，服務端通過這個隨機值進行對稱加密，隨機值即作爲加解密的鑰匙
- 傳輸加密後的信息
- 客戶端解密信息
- Http和https的區別。
- https協議需要到ca申請證書或自制證書。
- http的信息是明文傳輸，https則是具有安全性的ssl加密。
- http是直接與TCP進行數據傳輸，而https是經過一層SSL（OSI表示層），用的端口也不一樣，前者是80（需要國內備案），後者是443。
- http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
- 什麼是分塊傳送。
- HTTP1.1 協議（RFC2616）開始支持獲取文件的部分內容，這爲並行下載以及斷點續傳提供了技術支持。它通過在 Header 裏兩個參數實現的，客戶端發請求時對應的是 Range ，服務器端響應時對應的是 Content-Range。
- Session和cookie的區別。
- cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。
- Cookie的安全性一般，他人可通過分析存放在本地的Cookie並進行Cookie欺騙。在安全性第一的前提下，選擇Session更優。重要交互信息比如權限等就要放在Session中，一般的信息記錄放Cookie就好了
- 單個Cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個Cookie。
- Session 可以放在 文件、數據庫或內存中，比如將Session保存在redis中。由於一定時間內它是保存在服務器上的，當訪問增多時，會較大地佔用服務器的性能。考慮到減輕服務器性能方面，應當適時使用Cookie。
- Session 的運行依賴Session ID，而 Session ID 是存在 Cookie 中的，也就是說，如果瀏覽器禁用了 Cookie，Session 也會失效（但是可以通過其它方式實現，比如在 url 中傳遞 Session ID）。
- 用戶驗證這種場合一般會用 Session。因此，維持一個會話的核心就是客戶端的唯一標識，即Session ID。