TCP、UDP的區別
1、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發送數據之前不需要建立連接
2、TCP提供可靠的服務。也就是說，通過TCP連接傳送的數據，無差錯，不丟失，不重復，且按序到達;UDP盡最大努力交付，即不保證可靠交付
Tcp通過校驗和，重傳控制，序號標識，滑動窗口、確認應答實現可靠傳輸。如丟包時的重發控制，還可以對次序亂掉的分包進行順序控制。
3、UDP具有較好的實時性，工作效率比TCP高，適用於對高速傳輸和實時性有較高要求的通信或廣播通信。
4.每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信
5、TCP對系統資源要求較多，UDP對系統資源要求較少。
HTTP與TCP的區別和聯系
1. HTTP協議與TCP/IP協議的關系
HTTP屬於應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。
IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠地傳遞數據包，使得網絡上接收端收到發送端所發出的所有包，並且順序與發送順序一致。TCP協議是可靠的、面向連接的。
HTTP負責傳輸數據。
2. 如何理解HTTP協議是無狀態的
HTTP協議是無狀態的，指的是協議對於事務處理沒有記憶能力，服務器不知道客戶端是什么狀態。也就是說，打開一個服務器上的網頁和上一次打開這個服務器上的網頁之間沒有任何聯系。
HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協議（無連接）。
3. 什么是長連接、短連接？
在HTTP/1.0中默認使用短連接。也就是說，客戶端和服務器每進行一次HTTP操作，就建立一次連接，任務結束就中斷連接。當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。
而從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭加入這行代碼：
Connection:keep-alive 在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。
HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。
4、HTTP請求方式，Get與Post區別
（1） 在客戶端，Get方式通過URL提交數據，數據在URL中可以看到；POST方式，數據放置在HEADER中，以表單方式提交。
（2） GET方式提交的數據有長度限制（1024字節），而POST則沒有此限制。
（3） 安全性問題。正如在（1）中提到，使用 Get的時候，參數會顯示在地址欄上，而 Post不會。
所以，如果這些數據是中文數據而且是非敏感數據，那么使用 get（可使用URLEncode）；如果用戶輸入的數據不是中文字符而且包含敏感數據，那么還是使用 post為好。
（4） 安全的和冪等的。所謂安全的意味着該操作用於獲取信息而非修改信息。冪等的意味着對同一 URL的多個請求應該返回同樣的結果。完整的定義並不像看起來那樣嚴格。換句話說，GET請求一般不應產生副作用。從根本上講，其目標是當用戶打開一個鏈接時，她可以確信從自身的角度來看沒有改變資源。比如，新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認為是安全的和冪等的，因為它總是返回當前的新聞。反之亦然。POST請求就不那么輕松了。POST表示可能改變服務器上的資源的請求。仍然以新聞站點為例，讀者對文章的注解應該通過 POST請求實現，因為在注解提交之后站點已經不同了（比方說文章下面出現一條注解）。
5、請求頭中包含哪些數據
6、怎么實現斷點續傳
（https://blog.csdn.net/liang19890820/article/details/53215087）
HTTP1.1 協議（RFC2616）開始支持獲取文件的部分內容，這為並行下載以及斷點續傳提供了技術支持。
它通過在 Header 里兩個參數實現的，客戶端發請求時對應的是 Range ，服務器端響應時對應的是 Content-Range。
Range 頭部的格式有以下幾種情況：
Range: bytes=0-499 表示第 0-499 字節范圍的內容
Range: bytes=500-999 表示第 500-999 字節范圍的內容
Range: bytes=-500 表示最后 500 字節的內容
Range: bytes=500- 表示從第 500 字節開始到文件結束部分的內容
Range: bytes=0-0,-1 表示第一個和最后一個字節
Range: bytes=500-600,601-999 同時指定幾個范圍
Content-Range 用於響應頭中，在發出帶 Range 的請求后，服務器會在 Content-Range 頭部返回當前接受的范圍和文件總大小。一般格式：
Content-Range: bytes 0-499/22400
0－499 是指當前發送的數據的范圍，而 22400 則是文件的總大小。
而在響應完成后，返回的狀態碼也不同：
HTTP/1.1 200 Ok（不使用斷點續傳方式）
HTTP/1.1 206 Partial Content（使用斷點續傳方式）
增強校驗
在實際場景中，會出現一種情況，即在終端發起續傳請求時，URL 對應的文件內容在服務器端已經發生變化，此時續傳的數據肯定是錯誤的。如何解決這個問題了？顯然此時需要有一個標識文件唯一性的方法。
在 RFC2616 中也有相應的定義，比如實現 Last-Modified 來標識文件的最后修改時間，這樣即可判斷出續傳文件時是否已經發生過改動。同時 FC2616 中還定義有一個 ETag 的頭，可以使用 ETag 頭來放置文件的唯一標識。
Last-Modified
客戶端：If-Modified-Since
服務器： Last-Modified
都是用於記錄頁面最后修改時間的 HTTP 頭信息，只是 Last-Modified 是由服務器往客戶端發送的 HTTP 頭，而 If-Modified-Since 則是由客戶端往服務器發送的頭。
再次請求本地存在的 cache 頁面時，客戶端會通過 If-Modified-Since 頭將先前服務器端發過來的 Last-Modified 最后修改時間戳發送回去，這是為了讓服務器端進行驗證，
通過這個時間戳判斷客戶端的頁面是否是最新的，如果不是最新的，則返回新的內容，
如果是最新的，則返回 304 告訴客戶端其本地 cache 的頁面是最新的，於是客戶端就可以直接從本地加載頁面了，這樣在網絡上傳輸的數據就會大大減少，同時也減輕了服務器的負擔。
Etag
Etag（Entity Tags）主要為了解決 Last-Modified 無法解決的一些問題。
- 一些文件也許會周期性的更改，但是內容並不改變（僅改變修改時間），這時候我們並不希望客戶端認為這個文件被修改了，而重新 GET。
- 某些文件修改非常頻繁，例如：在秒以下的時間內進行修改（1s 內修改了 N 次），If-Modified-Since 能檢查到的粒度是 s 級的，這種修改無法判斷（或者說 UNIX 記錄 MTIME 只能精確到秒）。
- 某些服務器不能精確的得到文件的最后修改時間。
為此，HTTP/1.1 引入了 Etag。Etag 僅僅是一個和文件相關的標記，可以是一個版本標記，例如：v1.0.0；或者說 “627-4d648041f6b80” 這么一串看起來很神秘的編碼。但是 HTTP/1.1 標准並沒有規定 Etag 的內容是什么或者說要怎么實現，唯一規定的是 Etag 需要放在 “” 內。
If-Range
用於判斷實體是否發生改變，如果實體未改變，服務器發送客戶端丟失的部分，否則發送整個實體。一般格式：
If-Range: Etag | HTTP-Date
也就是說，If-Range 可以使用 Etag 或者 Last-Modified 返回的值。當沒有 ETage 卻有 Last-modified 時，可以把 Last-modified 作為 If-Range 字段的值。
例如：
If-Range: “627-4d648041f6b80”
If-Range: Fri, 22 Feb 2013 03:45:02 GMT
If-Range 必須與 Range 配套使用。如果請求報文中沒有 Range，那么 If-Range 就會被忽略。如果服務器不支持 If-Range，那么 Range 也會被忽略。
如果請求報文中的 Etag 與服務器目標內容的 Etag 相等，即沒有發生變化，那么應答報文的狀態碼為 206。如果服務器目標內容發生了變化，那么應答報文的狀態碼為 200。
用於校驗的其他 HTTP 頭信息：If-Match/If-None-Match、If-Modified-Since/If-Unmodified-Since。
工作原理
Etag 由服務器端生成，客戶端通過 If-Range 條件判斷請求來驗證資源是否修改。請求一個文件的流程如下：
第一次請求：
- 客戶端發起 HTTP GET 請求一個文件。
- 服務器處理請求，返回文件內容以及相應的 Header，其中包括 Etag（例如：627-4d648041f6b80）（假設服務器支持 Etag 生成並已開啟了 Etag）狀態碼為 200。
第二次請求（斷點續傳）：
- 客戶端發起 HTTP GET 請求一個文件，同時發送 If-Range（該頭的內容就是第一次請求時服務器返回的 Etag：627-4d648041f6b80）。
- 服務器判斷接收到的 Etag 和計算出來的 Etag 是否匹配，如果匹配，那么響應的狀態碼為 206；否則，狀態碼為 200。
檢測服務器是否支持斷點續傳
CURL 實現檢測：
[root@localhost ~]# curl -i --range 0-9 http://www.baidu.com/img/bdlogo.gif HTTP/1.1 206 Partial Content Date: Mon, 21 Nov 2016 05:26:29 GMT Server: Apache P3P: CP=" OTI DSP COR IVA OUR IND COM " Set-Cookie: BAIDUID=0CD0E23B4D4F739954DFEDB92BE6CE03:FG=1; expires=Tue, 21-Nov-17 05:26:29 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1 Last-Modified: Fri, 22 Feb 2013 03:45:02 GMT ETag: "627-4d648041f6b80" Accept-Ranges: bytes Content-Length: 10 Cache-Control: max-age=315360000 Expires: Thu, 19 Nov 2026 05:26:29 GMT Content-Range: bytes 0-9/1575 Connection: Keep-Alive Content-Type: image/gif
能夠找到 Content-Range，則表明服務器支持斷點續傳。有些服務器還會返回 Accept-Ranges，輸出結果 Accept-Ranges: bytes ，說明服務器支持按字節下載。