[TOC] 在PC瀏覽器的地址欄輸入一串URL，然后按Enter鍵這個頁面渲染出來，這個過程中都發生了什么事?這個是很多面試官喜歡問的一個問題 如果測試只是停留在表面上點點點，不知道背后的邏輯，是無法發現隱藏的bug，只能找一些頁面上看得到的bug。 測試人員如果想在技術上有所提升，必然要都懂接口（API）測試，這也是近來年越來越多的公司意識到接口測試的重要性，招聘的時候要招一個中高級的測試人員，接口測試是必備技能了。 <br /> <details> <summary>一、在PC瀏覽器的地址欄輸入一串URL，然后按Enter鍵這個頁面渲染出來，這個過程中都發生了什么事? </summary> ``` 1、首先，在瀏覽器地址欄中輸入url，先解析url，檢測url地址是否合法 2、瀏覽器先查看瀏覽器緩存-系統緩存-路由器緩存，如果緩存中有，會直接在屏幕中顯示頁面內容。若沒有，則跳到第三步操作。 瀏覽器緩存：瀏覽器會記錄DNS一段時間，因此，只是第一個地方解析DNS請求； 操作系統緩存：如果在瀏覽器緩存中不包含這個記錄，則會使系統調用操作系統，獲取操作系統的記錄(保存最近的DNS查詢緩存)； 路由器緩存：如果上述兩個步驟均不能成功獲取DNS記錄，繼續搜索路由器緩存； ISP緩存：若上述均失敗，繼續向ISP搜索。 3、在發送http請求前，需要域名解析(DNS解析)，解析獲取相應的IP地址。 4、瀏覽器向服務器發起tcp連接，與瀏覽器建立tcp三次握手。 5、握手成功后，瀏覽器向服務器發送http請求，請求數據包。 6、服務器處理收到的請求，將數據返回至瀏覽器 7、瀏覽器收到HTTP響應 8、瀏覽器解碼響應，如果響應可以緩存，則存入緩存。 9、瀏覽器發送請求獲取嵌入在HTML中的資源（html，css，javascript，圖片，音樂······），對于未知類型，會彈出對話框。 10、瀏覽器發送異步請求。 11、頁面全部渲染結束 ``` </details> <br /> <details> <summary>二、get和post的區別？</summary> ``` 1、概括 對于GET方式的請求，瀏覽器會把http header和data一并發送出去，服務器響應200（返回數據）； 而對于POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據） 2、區別： (1) get參數通過url傳遞，post放在request body中。 (2）get請求在url中傳遞的參數是有長度限制的，而post沒有。 (3) get比post更不安全，因為參數直接暴露在url中，所以不能用來傳遞敏感信息。 (4) get請求只能進行url編碼，而post支持多種編碼方式。 (5) get請求會瀏覽器主動cache，而post支持多種編碼方式。 (6) get請求參數會被完整保留在瀏覽歷史記錄里，而post中的參數不會被保留。 (7) GET和POST本質上就是TCP鏈接，并無差別。但是由于HTTP的規定和瀏覽器/服務器的限制，導致他們在應用過程中體現出一些不同。 (8) GET產生一個TCP數據包；POST產生兩個TCP數據包。 ``` </details> <br /> <details> <summary>三、cookies機制和session機制的區別?</summary> ``` cookies數據保存在客戶端，session數據保存在服務器端； cookies可以減輕服務器壓力，但是不安全，容易進行cookies欺騙； session較安全，但占用服務器資源 ``` </details> <br /> <details> <summary>四、常見的HTTP狀態碼有哪些？</summary> ``` 1XX Informational（請求正在處理） 2XX Success（請求成功） 3XX Redirection（重定向） 需要進行附加操作以完成請求 4XX Client Error（客戶端錯誤） 5XX Server Error（服務器錯誤） ------------------------------------------------------------ 200 請求已成功，請求所希望的響應頭或數據體將隨此響應返回。 201 請求已經被實現，而且有一個新的資源已經依據請求的需要而建立，且其 URI 已經隨Location 頭信息返回 202 服務器已接受請求，但尚未處理 301 （永久移動） 請求的網頁已永久移動到新位置。 服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。 302 （臨時移動） 服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以后的請求。 303 （查看其他位置） 請求者應當對不同的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。 304 （未修改） 自從上次請求后，請求的網頁未修改過。 服務器返回此響應時，不會返回網頁內容。 305 （使用代理） 請求者只能使用代理訪問請求的網頁。 如果服務器返回此響應，還表示請求者應使用代理。 307 （臨時重定向） 服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以后的請求。 401 當前請求需要用戶驗證。如果當前請求已經包含了 Authorization 證書，那么401響應代表著服務器驗證已經拒絕了那些證書 403 服務器已經理解請求，但是拒絕執行它。與401響應不同的是，身份驗證并不能提供任何幫助，而且這個請求也不應該被重復提交 404 請求失敗，請求所希望得到的資源未被在服務器上發現 500 服務器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。一般來說，這個問題都會在服務器的程序碼出錯時出現。 501 服務器不支持當前請求所需要的某個功能。當服務器無法識別請求的方法，并且無法支持其對任何資源的請求。 502 作為網關或者代理工作的服務器嘗試執行請求時，從上游服務器接收到無效的響應。 503 由于臨時的服務器維護或者過載，服務器當前無法處理請求。這個狀況是臨時的，并且將在一段時間以后恢復 # 301和302的區別： 301和302狀態碼都表示重定向，就是說瀏覽器在拿到服務器返回的這個狀態碼后會自動跳轉到一個新的URL地址， 這個地址可以從響應的Location首部中獲取（用戶看到的效果就是他輸入的地址A瞬間變成了另一個地址B）—— 這是它們的共同點。 他們的不同在于。301表示舊地址A的資源已經被永久地移除了(這個資源不可訪問了)，搜索引擎在抓取新內容的 同時也將舊的網址交換為重定向之后的網址；302表示舊地址A的資源還在（仍然可以訪問），這個重定向只 是臨時地從舊地址A跳轉到地址B，搜索引擎會抓取新的內容而保存舊的網址。 SEO302好于301 # 重定向原因： 1. 網站調整（如改變網頁目錄結構）； 2. 網頁被移到一個新地址； 3. 網頁擴展名改變(如應用需要把.php改成.Html或.shtml)。 這種情況下，如果不做重定向，則用戶收藏夾或搜索 引擎數據庫中舊地址只能讓訪問客戶得到一個404頁面錯誤信息，訪問流量白白喪失；再者某些注冊了多個域名 的網站，也需要通過重定向讓訪問這些域名的用戶自動跳轉到主站點等。 ``` </details> <br /> <details> <summary>五、http協議有哪幾種請求方式？</summary> ``` GET, POST 和 HEAD、OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。 ``` </details> <br /> <details> <summary>六、http和https區別？</summary> ``` HTTP協議傳輸的數據都是未加密的，也就是明文的，因此使用HTTP協議傳輸隱私信息非常不安全， 為了保證這些隱私數據能加密傳輸，于是網景公司設計了SSL（Secure Sockets Layer）協議用 于對HTTP協議傳輸的數據進行加密，從而就誕生了HTTPS。簡單來說，HTTPS協議是由SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全。 HTTPS和HTTP的區別主要如下： 總的來說： HTTPS=SSL+HTTP 1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。 2、http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。 3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。 （這個只是默認端口不一樣，實際上端口是可以改的） 4、http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、 身份認證的網絡協議，比http協議安全。 ``` </details> <br /> <details> <summary>七、http 報文格式是怎樣的？</summary> ``` 請求報文包含三部分： a、請求行：包含請求方法、URI、HTTP版本信息 b、請求頭部（headers）字段 c、請求內容實體(body) 響應報文包含三部分： a、狀態行：包含HTTP版本、狀態碼、狀態碼的原因短語 b、響應頭部（headers）字段 c、響應內容(body)實體 ``` </details> <br /> <details> <summary>八、常見的 POST 提交數據方式</summary> ``` application/x-www-form-urlencoded multipart/form-data application/json text/xml ``` </details> <br /> <details> <summary>九、什么是DNS？</summary> ``` 域名解析服務。將主機名轉換為IP地址。如將http://www.cnblogs.com/主機名轉換為IP地址：211.137.51.78 ``` </details> <br /> <details> <summary>十、什么是Http協議無狀態協議?怎么解決Http協議無狀態協議?</summary> ``` (1)、無狀態協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息 (2)、無狀態協議解決辦法： 通過1、Cookie 2、通過Session會話保存。 ``` </details> <br /> <details> <summary>十一、TCP和UDP的區別？</summary> ``` 1. TCP和UDP區別 1） 連接 TCP是面向連接的傳輸層協議，即傳輸數據之前必須先建立好連接。 UDP無連接。 2） 服務對象 TCP是點對點的兩點間服務，即一條TCP連接只能有兩個端點； UDP支持一對一，一對多，多對一，多對多的交互通信。 3） 可靠性 TCP是可靠交付：無差錯，不丟失，不重復，按序到達。 UDP是盡最大努力交付，不保證可靠交付。 4）擁塞控制，流量控制 TCP有擁塞控制和流量控制保證數據傳輸的安全性。 UDP沒有擁塞控制，網絡擁塞不會影響源主機的發送效率。 5） 報文長度 TCP是動態報文長度，即TCP報文長度是根據接收方的窗口大小和當前網絡擁塞情況決定的。 UDP面向報文，不合并，不拆分，保留上面傳下來報文的邊界。 6) 首部開銷 TCP首部開銷大，首部20個字節。 UDP首部開銷小，8字節。（源端口，目的端口，數據長度，校驗和） 2. TCP和UDP適用場景 從特點上我們已經知道，TCP 是可靠的但傳輸速度慢，UDP 是不可靠的但傳輸速度快。因此在選用具體協議通信時，應該根據通信數據的要求而決定。 若通信數據完整性需讓位與通信實時性，則應該選用TCP 協議（如文件傳輸、重要狀態的更新等）；反之，則使用 UDP 協議（如視頻傳輸、實時通信等）。 ``` </details> <br /> <details> <summary>十二、socket建立連接的過程？</summary> <br /> 首先服務器建立監聽, socket , bind , listen 然后客戶端發送請求, connect , send 最后連接確認, accept , response ## **詳細過程：** 建立Socket連接至少需要一對套接字，其中一個運行于客戶端，稱為ClientSocket ，另一個運行于服務器端，稱為ServerSocket 。 套接字之間的連接過程分為三個步驟：服務器監聽，客戶端請求，連接確認。 1、服務器監聽：服務器端套接字并不定位具體的客戶端套接字，而是處于等待連接的狀態，實時監控網絡狀態，等待客戶端的連接請求。 2、客戶端請求：指客戶端的套接字提出連接請求，要連接的目標是服務器端的套接字。 為此，客戶端的套接字必須首先描述它要連接的服務器的套接字，指出服務器端套接字的地址和端口號，然后就向服務器端套接字提出連接請求。 3、連接確認：當服務器端套接字監聽到或者說接收到客戶端套接字的連接請求時，就響應客戶端套接字的請求，建立一個新的線程，把服務器端套接字的描述發給客戶端，一旦客戶端確認了此描述，雙方就正式建立連接。 而服務器端套接字繼續處于監聽狀態，繼續接收其他客戶端套接字的連接請求。 </details> <br /> <details> <summary>十三、tcp的三次握手與四次揮手</summary> <br /> ## **TCP 三次握手建立連接** ### **① 三次握手過程詳解** 三次握手的原文是?`three-way handshake`，整個名詞的可以翻譯為：**需要三個步驟才能建立握手/連接的機制**。當然，三次握手也可以叫?`three-message handshake`，通過三條消息來建立的握手/連接。 <br /> 進行三次握手的主要作用就是為了確認雙方的接收能力和發送能力是否正常、指定自己的?**初始化序列號(Init Sequense Number, ?`ISN`)**?為后面的可靠性傳輸做準備。 <br /> 三次握手過程如下圖：  回顧一下圖中字符的含義： * `SYN`：連接請求/接收 報文段 * `seq`：發送的第一個字節的序號 * `ACK`：確認報文段 * `ack`：確認號。希望收到的下一個數據的第一個字節的序號 <br /> **1）第一次握手**：客戶端向服務端發送一個 SYN 報文（SYN = 1），并指明客戶端的初始化序列號 ISN(x)，即圖中的 seq = x，表示本報文段所發送的數據的第一個字節的序號。此時客戶端處于?`SYN_Send`?狀態。 > `SYN-SENT`?：在發送連接請求后等待匹配的連接請求 <br /> **2）第二次握手**：服務器收到客戶端的 SYN 報文之后，會發送 SYN 報文作為應答（SYN = 1），并且指定自己的初始化序列號 ISN(y)，即圖中的 seq = y。同時會把客戶端的 ISN + 1 作為確認號 ack 的值，表示已經收到了客戶端發來的的 SYN 報文，希望收到的下一個數據的第一個字節的序號是 x + 1，此時服務器處于?`SYN_REVD`?的狀態。 > `SYN-RECEIVED`：在收到和發送一個連接請求后等待對連接請求的確認 <br /> **3）第三次握手**：客戶端收到服務器端響應的 SYN 報文之后，會發送一個 ACK 報文，也是一樣把服務器的 ISN + 1 作為 ack 的值，表示已經收到了服務端發來的的 SYN 報文，希望收到的下一個數據的第一個字節的序號是 y + 1，并指明此時客戶端的序列號 seq = x + 1（初始為 seq = x，所以第二個報文段要 +1），此時客戶端處于?`Establised`?狀態。 服務器收到 ACK 報文之后，也處于?`Establised 狀態`，至此，雙方建立起了 TCP 連接。 > `ESTABLISHED`：代表一個打開的連接，數據可以傳送給用戶 <br /> ### **② 為什么要三次握手** 三次握手的目的是建立可靠的通信信道，說到通訊，簡單來說就是數據的發送與接收，而三次握手最主要的目的就是**雙方確認自己與對方的發送與接收是正常的**。 只有經過三次握手才能確認雙發的收發功能都正常，缺一不可： * 第一次握手（客戶端發送 SYN 報文給服務器，服務器接收該報文）：客戶端什么都不能確認；服務器確認了對方發送正常，自己接收正常 * 第二次握手（服務器響應 SYN 報文給客戶端，客戶端接收該報文）： 客戶端確認了：自己發送、接收正常，對方發送、接收正常； 服務器確認了：對方發送正常，自己接收正常 * 第三次握手（客戶端發送 ACK 報文給服務器）： 客戶端確認了：自己發送、接收正常，對方發送、接收正常； 服務器確認了：自己發送、接收正常，對方發送、接收正常 <br /> ## **TCP 四次揮手釋放連接** ### **① 四次揮手過程詳解** 建立一個 TCP 連接需要三次握手，而終止一個 TCP 連接要經過四次揮手（也有將四次揮手叫做四次握手的）。這是由于 TCP 的**半關閉**（half-close）特性造成的，TCP 提供了連接的一端在結束它的發送后還能接收來自另一端數據的能力。 <br /> TCP 連接的釋放需要發送四個包（執行四個步驟），因此稱為四次揮手(`Four-way handshake`)，**客戶端或服務端均可主動發起揮手動作**。  回顧一下上圖中符號的意思： * `FIN`?：連接終止位 * `seq`：發送的第一個字節的序號 * `ACK`：確認報文段 * `ack`：確認號。希望收到的下一個數據的第一個字節的序號 剛開始雙方都處于`ESTABLISHED`?狀態，假設是客戶端先發起關閉請求。四次揮手的過程如下： **1）第一次揮手**：客戶端發送一個 FIN 報文（請求連接終止：FIN = 1），報文中會指定一個序列號 seq = u。并**停止再發送數據，主動關閉 TCP 連接**。此時客戶端處于?`FIN_WAIT1`?狀態，等待服務端的確認。 > `FIN-WAIT-1`?- 等待遠程TCP的連接中斷請求，或先前的連接中斷請求的確認； **2）第二次揮手**：服務端收到 FIN 之后，會發送 ACK 報文，且把客戶端的序號值 +1 作為 ACK 報文的序列號值，表明已經收到客戶端的報文了，此時服務端處于?`CLOSE_WAIT`?狀態。 > `CLOSE-WAIT`?- 等待從本地用戶發來的連接中斷請求； **此時的 TCP 處于半關閉狀態，客戶端到服務端的連接釋放**。客戶端收到服務端的確認后，進入`FIN_WAIT2`（終止等待 2）狀態，等待服務端發出的連接釋放報文段。 > `FIN-WAIT-2`?- 從遠程TCP等待連接中斷請求； **3）第三次揮手**：如果服務端也想斷開連接了（沒有要向客戶端發出的數據），和客戶端的第一次揮手一樣，發送 FIN 報文，且指定一個序列號。此時服務端處于?`LAST_ACK`?的狀態，等待客戶端的確認。 > `LAST-ACK`?- 等待原來發向遠程TCP的連接中斷請求的確認； **4）第四次揮手**：客戶端收到 FIN 之后，一樣發送一個 ACK 報文作為應答（ack = w+1），且把服務端的序列值 +1 作為自己 ACK 報文的序號值（seq=u+1），此時客戶端處于?**`TIME_WAIT`?（時間等待）狀態**。 > `TIME-WAIT`?- 等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認； ?? 注意 ！！！這個時候由服務端到客戶端的 TCP 連接并未釋放掉，**需要經過時間等待計時器設置的時間 2MSL（一個報文的來回時間） 后才會進入?`CLOSED`?狀態**（這樣做的目的是確保服務端收到自己的 ACK 報文。如果服務端在規定時間內沒有收到客戶端發來的 ACK 報文的話，服務端會重新發送 FIN 報文給客戶端，客戶端再次收到 FIN 報文之后，就知道之前的 ACK 報文丟失了，然后再次發送 ACK 報文給服務端）。服務端收到 ACK 報文之后，就關閉連接了，處于?`CLOSED`?狀態。 <br /> ### **② 為什么要四次揮手** 由于 TCP 的**半關閉**（half-close）特性，TCP 提供了連接的一端在結束它的發送后還能接收來自另一端數據的能力。 任何一方都可以在數據傳送結束后發出連接釋放的通知，待對方確認后進入**半關閉狀態**。當另一方也沒有數據再發送的時候，則發出連接釋放通知，對方確認后就**完全關閉**了TCP連接。 <br /> **通俗的來說，兩次握手就可以釋放一端到另一端的 TCP 連接，完全釋放連接一共需要四次握手**。 <br /> 舉個例子：A 和 B 打電話，通話即將結束后，A 說 “我沒啥要說的了”，B 回答 “我知道了”，于是 A 向 B 的連接釋放了。但是 B 可能還會有要說的話，于是 B 可能又巴拉巴拉說了一通，最后 B 說“我說完了”，A 回答“知道了”，于是 B 向 A 的連接釋放了，這樣整個通話就結束了。 </details> <br /> <details> <summary>網頁加載慢，你知道幾種原因？ </summary> <br /> **1.帶寬不足**，首先想到的就是自己網速的問題，但是一般網速在1M以上的，打開網頁一般不會是很慢的。網站服務器的帶寬不夠的話，當大量用戶訪問的時候，網頁的加載也是很慢的，這就是網絡的出口端和入口端兩個方面 **2.硬件配置低**，本機的配置也會是一方面的，但是只要不是老賽揚單核+512M的配置，一般不會是電腦配置的問題。服務器端的配置也是同樣的道理。 **3.CPU或者是內存被占滿的時候**，打開網頁很是會很慢的，因為整個電腦都很慢 **4..DNS解析慢**，域名的解析是需要專門的域名解析服務器來完成的，DNS解析包括往復解析的次數及每次解析所花費的時間，它們兩者的積即是DNS解析所耗費的總時間，在http請求的過程中，域名解析和建立連接占的時間很多。 **5.JS阻塞請求**，寫的js代碼出現問題，解析就會花費很長時間，這兩個js請求之間會出現一個很大的空隙，就會導致這段時間的資源加載都被阻塞住， **6.接受數據時間過長**，http請求的大部分時間應該花在后面幾個階段，比如等待響應和接收數據。但是，如果接收數據的時間太長了，長到數百毫秒甚至以秒計算的時候，那也是有問題的。這種情況一般是因為下載的內容太重了，例如大圖片、大腳本等。這類問題可以使用GZIP壓縮、圖片壓縮或者JS/CSS的minify等手段來解決。 **7.加載某個資源太慢**，如果某個請求比其他的請求多出很多的時間，那么一般情況就是某個資源的加載太慢，導致了整個網頁變慢，原因有可能是1)資源在第三方站點上，他們很慢；2)這個資源太大了；3)這個資源使用的域名有問題 **8.后端代碼問題**，主要有代碼冗余、數據庫發生鎖死、動態請求時間過長等，這就需要RD優化一切可以優化的東西了 **9.前端頁面請求的資源過多**，onload之前如果有幾百行，速度自然會慢的，如果請求的資源不存在，那么速度將會更慢 **10.網頁本身中包含了追蹤或者是分析用戶的工具**，從而導致網頁的加載時間變的慢，比如之前海盜灣中會給用戶的電腦插入挖礦的js腳本 </details> <br />