前兩天面試遇到一個問題：如果讓你對一個項目通信協議進行選擇的話，你會選擇Http還是Tcp(當時問的是套接字，其實套接字還有UDP啦，我好像也沒去講)協議？感覺當時腦子轉的不太靈活。而且以爲Http keep-alive與Tcp keep-alive是差不多的，所以根本沒去講兩者之間的keep-alive。每次面試回答問題都有點着急，所以思考不夠。實際上兩者是不同的，下面分別介紹一下。
首先Http是建立在Tcp協議的基礎上的，Tcp是傳輸層的協議，Http是應用層協議。Http底層也是通過Tcp傳輸的。
HTTP keep-alive
Http是一個”請求-響應”協議，它的keep-alive主要是爲了讓多個http請求共享一個Tcp連接，以避免每個Http又新建一個Tcp連接。每個Http服務器默認的keep-alive時間可能是不一樣的。
TCP keep-alive
Tcp的keep-alive是Tcp協議的一種保鮮裝置，當Tcp請求響應結束後，經過tcp_keep-alive_time時間後，服務器會發出監測包去看看改Tcp連接是否還是繼續連接的，是否已經出現了網絡問題，是否客戶端崩潰了等等問題。如果發現出現了問題，那麼服務端就會去關閉連接，把這個Tcp連接關閉。
關於TCP心跳
在目前這兩年的移動互聯網火熱的環境下，推送應用的非常多。推送實現的就是通過TCP長連接實現的，因爲移動網絡很多時候都會不穩定，另外NAT過一段時間就會刷新,所以而要如何保證客戶端和服務器端連接就成了一個問題。TCP心跳包就是客戶端監測連接的，它先發送一個心跳包到服務器，服務器再Ask，通過這種方式判斷是否目前的長連接是否可用，如果斷了，則通知上層應用，並關閉連接，另外發送心跳包也是避免一段時間都沒有通信，NAT超時，NAT表被刷新，導致連接失效。
HTTP與TCP keep-alive聯繫
直接介紹一個場景就可能更容易明白了。客戶端發送了一個Http請求，服務器響應後，判斷這個Http是否是keep-alive的，如果不是則關閉連接。如果是keep-alive，則等待keep-alive time後再關閉，如果這期間再收到一個http 請求，則繼續等待最後一個請求的keep-alive time時間，直到keep-alive time時間內沒有收到請求，則關閉。
上面是HTTP keep-alive的，而TCP是它下一層的協議，本身TCP是長連接的，除非主動關閉。HTTP的keep-alive time一般是15ms, 30ms之類的，如果是超過了HTTP的keep-alive time時間，則HTTP會關閉TCP連接。本身TCP是不會關閉連接的，TCP的keep alive是TCP的保鮮裝置，在keep alive timeout 後服務端發送一個監測包來判斷連接是否仍保持着，如果還是可連接，則繼續保持，它不會主動關閉連接的。而心跳包是爲了防止NAT超時。
雜記
對於問題要多問爲什麼，要去細細探究，注意細節。瞭解與理解是不同的，另外也需要在遇到問題的時候，充分利用自己的知識分析問題，心態要好。找個時間看一下HttpUrlConnection跟okHttp的源碼。
加強表述