1. 程式人生 > >http與tcp面試題4

http與tcp面試題4

 

-4.DNS使用的協議(既使用TCP也使用UDP)yes!

      1)、首先了解一下TCP與UDP傳送位元組的長度限制:
               
UDP報文的最大長度為512位元組,而TCP則允許報文長度超過512位元組。當DNS查詢超過512位元組時,協議的TC標誌出現刪除標誌,這時則使用TCP傳送。通常傳統的UDP報文一般不會大於512位元組。
       2)、

區域傳送時使用TCP(夫域名服務向主域名伺服器請求資料時),主要有一下兩點考慮:
               由於dns是一個分散式系統設計,因此會存在主從伺服器之間的資料傳送。

輔域名伺服器會定時(一般3小時)向主域名伺服器進行查詢以便了解資料是否有變動。如有變動,則會執行一次區域傳送,進行資料同步。區域傳送將使用TCP而不是UDP,因為資料同步傳送的資料量比一個請求和應答的資料量要多得多。
TCP是一種可靠的連線,保證了資料的準確性。
       3)、

域名解析時使用UDP協議
           
   客戶端向DNS伺服器查詢域名,一般返回的內容都不超過512位元組,用UDP傳輸即可。不用經過TCP三次握手,這樣DNS伺服器負載更低,響應更快。雖然從理論上說,客戶端也可以指定向DNS伺服器查詢的時候使用TCP,但事實上,很多DNS伺服器進行配置的時候,僅支援UDP查詢包。
 

-3.Session和cookie的區別。

  • 1)儲存位置不同
  • Cookie儲存在客戶端,未設定儲存時間的Cookie,關閉瀏覽器會話Cookie就會被刪除;設定了儲存時間的Cookie儲存在使用者裝置的磁碟中知道過期,同時Cookie在客戶端所以可以偽造,不是十分安全,敏感資料不易儲存。
  • Session儲存在伺服器端,儲存在IIS的程序開闢的記憶體中,而Session過多會消耗伺服器資源,所以儘量少使用Session。
  • (2)Session與Cookie的耦合
  • Session是伺服器用來跟蹤使用者的一種手段,每個Session都有一個唯一標識:session ID。當服務端生成一個Session時就會向客戶端傳送一個Cookie儲存到客戶端,這個Cookie儲存的是Session的SessionId這樣才能保證客戶端發起請求後,使用者能夠與伺服器端成千上萬的Session進行匹配,同時也保證了不同頁面之間傳值的正確性.
  • (3)儲存資料型別不同:
  • Session能夠儲存任意的JAVA物件,Cookie只能儲存String型別的物件。

-2.HTTP的長連線是什麼意思。

長連線相對於短連結來講。http1.0預設短連結,http1.1預設長連線,短長是指一次tcp連線建立和斷開的時長。

  長連線是指客戶端與服務端建立連線後,不會因完成了一次請求後,它們之間的連線主動關閉。而短連結是指,客戶端和服務端建立連線後,完成一次http請求呢和http響應,他們之間的tcp連線主動關閉。

後續的讀寫操作會繼續使用這個連結。 如果一個連線兩小時內都沒有任何動作,伺服器會向客戶端傳送一個探測報文段、根據客戶端主機相應探測4個客戶端狀態,

①、客戶端正常時,且伺服器可達。此時客戶端TCP響應正常,伺服器將定時器復位。

②、客戶端已經崩潰,並且關閉或正在重啟,客戶端不能響應TCP,伺服器將無法收到客戶端對探測器的響應。伺服器總共傳送10個這樣的探測,每間隔75秒。如伺服器沒有收到任何響應,他就認為客戶端已經關閉並終止連線。

③、客戶端崩潰,但已重啟。伺服器將對其保持探測響應,這個響應是一個復位,使得伺服器終止這個連線。

④、 客戶機正常執行,但是伺服器不可達。這種與②類。
      
 由上可以看出,長連線可以省去較多的TCP建立和關閉操作,減少浪費,節約時間。對於頻繁請求資源的客戶端適合使用長連線。在長連線的應用場景下,client端一般不會主動關閉連線,當client與server之間的連線一直不關閉,隨著客戶端連線越來越多,server會保持過多連線。這時候server端需要採取一些策略,如關閉一些長時間沒有請求發生的連線,這樣可以避免一些惡意連線導致server端服務受損;如果條件允許則可以限制每個客戶端的最大長連線數,這樣可以完全避免惡意的客戶端拖垮整體後端服務,例如:資料庫的連線用長連線。

-1.簡述HTTP請求的報文格式。

客戶端與服務端通訊時傳輸的內容我們稱之為報文。

  客戶端傳送給伺服器的稱為”請求報文“,伺服器傳送給客戶端的稱為”響應報文“。


 

0.HTTP有哪些method。

 ★ GET:獲取資源。
      ★ POST:表單提交。
      ★ HEAD:獲取報頭資訊,HEAD 方法與 GET 方法類似,但http響應中沒有資料主體的返回。
      ★ PUT 與PATCH:更新資源,PUT 對後臺來說 PUT 方法的引數是一個完整的資源物件,它包含了物件的所有欄位,PATCH 對後臺來說 PATCH 方法的引數只包含我們需要修改的資源物件的欄位。
      ★ DELETE:刪除資源。
      ★ OPTIONS:獲取目標資源所支援的通訊選項,使用 OPTIONS 方法對伺服器發起請求,以檢測伺服器支援哪些 HTTP 方法。

1.如何理解HTTP協議的無狀態性。

       HTTP協議是無狀態的,指的是HTTP協議對於事務處理沒有記憶功能,伺服器不知道客戶端是什麼狀態。相當於,開啟一個伺服器上的網頁與上一次開啟這個伺服器上的網頁之間沒有任何聯絡。HTTP是一個無狀態的面向連線的協議,無狀態不代表HTTP不能保持TCP連線,更不代表HTTP使用的是UDP協議(無連線)。

2.簡述Http請求get和post的區別以及資料包格式。

    ▶ GET請求可被快取,POST請求不能被快取。
    ▶ GET請求被保留著瀏覽器歷史記錄中,POST請求不會被保留。
    ▶ GET請求能被收藏至書籤中,POST請求不能被收藏至書籤。
    ▶ GET請求不應在處理敏感資料時使用,POST可以使用者處理敏感資料。
    ▶ GET請求有長度限制,POST請求沒有長度限制。
    ▶POST不限制提交的資料型別,所以POST可以提交檔案到伺服器。

本質原因:get的資料放在http請求頭中,post請求放在http請求的資料體中
--------------------- 

3、TIME_WAIT和CLOSE_WAIT的區別

      CLOSE_WAIT:等待關閉,是被動關閉連線形成的,也就是第二次揮手時產生的狀態。也就是當對方close一個SOCKET後傳送FIN報文給自己,系統會迴應一個ACK報文給對方,此時進入CLOSE_WAIT狀態。接著,我們需要考慮的事情是檢視是否還有資料傳送給對方,如果沒有就可以close這個連結,傳送FIN給對方,也既關閉連線。所以在CLOSE_WAIT狀態時,需要檢視自己是否需要關閉連線。

      TIME_WAIT:是主動關閉連線方形成的,表示收到了對方的FIN報文,併發送ACK報文,等待2MSL(Maximum Segment Lifetime:報文最大生存時間)約4分鐘時間後進入CLOSE狀態。主要是防止最後一個ACK丟失,由於TIME_WAIT等待時間較長,因此server端儘量減少關閉。

4、為什麼需要TIME_WAIT狀態?

     假設最終的ACK丟失,伺服器將重新發送FIN,客戶端必須維護TCP狀態資訊以便可以重發最終的ACK,否則傳送RST,結果Server認為發生錯誤。TCP實現必須可靠的終止兩端的連線(雙工關閉),Client必須進入TIME_WAIT狀態,因為最總的ACK可能傳送失敗。

5、為什麼TIME_WAIT狀態要保持2MSL這麼長時間?

     如果TIME_WAIT狀態保持時間不足2MSL,第一個連線可以正常關閉,但如果有相同的第二個連接出現,第一個連線的重複報文到達,就會干擾第二個連線。TCP必須防止某個連線的重複報文在連線終止後出現,所以讓TIME_WAIT狀態等待時間大於2MSL,連線響應方向上的TCP報文要麼完全響應完畢,要麼被丟棄。建立二次連線時,就不會混淆。