Java—TCP与HTTP连接
輸入一個url到瀏覽器頁面展示過程：
TCP傳輸控制協議/UDP用戶數據報協議：
- TCP面向連接、字節流、全雙工的可靠信道，發送端時經過各層時都要附加上相應層的協議頭和協議尾（僅數據鏈路層需要封裝協議尾）部分，與原數據大小不同。
- UDP無連接、報文流、不可靠信道，發送時與原數據大小相同。
- 接收緩沖區被TCP和UDP用來緩存網絡上來的數據，一直保存到應用進程讀走為止。對于TCP，如果應用進程一直沒有讀取，buffer滿了之后，發生的動作是：通知對端TCP協議中的窗口關閉。這個便是滑動窗口的實現。保證TCP套接口接收緩沖區不會溢出，從而保證了TCP是可靠傳輸。因為對方不允許發出超過所通告窗口大小的數據。 這就是TCP的流量控制，如果對方無視窗口大小而發出了超過窗口大小的數據，則接收方TCP將丟棄它。
- UDP：當套接口接收緩沖區滿時，新來的數據報無法進入接收緩沖區，此數據報就被丟棄。UDP是沒有流量控制的;快的發送者可以很容易地就淹沒慢的接收者，導致接收方的UDP丟棄數據報。
流量控制：
TCP中采用滑動窗口來進行流量控制，滑動窗口的大小意味著接收方還有多大的緩沖區可以用于接收數據。發送方可以通過滑動窗口的大小來確定應該發送多少字節的數據。當滑動窗口為0時，發送方一般不能再發送數據報。
擁塞控制：
擁塞窗口指某一源端數據流在一個RTT內可以最多發送的數據包數。
防止發送方發的太快，使得網絡來不及處理，從而導致網絡擁塞
- 慢啟動： 網絡傳輸剛開始時，并不知道網絡的實際情況，所以采取一種試探的方式控制數據的發送速率。慢啟動階段，數據的發送速率以指數方式增長，即就是擁塞窗口的增長，每次都是收到確認報文段數量的2倍。可以看出慢啟動并不慢，擁塞窗口增長的速度很快。所以，為其設置了一個慢啟動門限，當達到門限時，就進入到擁塞避免階段。
- 擁塞避免： 當擁塞窗口的大小采用慢啟動方式增長到慢啟動門限時，就進入擁塞避免階段，擁塞避免階段不再以指數形式增長擁塞窗口，而是每經過一個往返時間RTT就將發送方的擁塞窗口+1， 使其增長速度減緩。按照線性方式增長。如果發生網絡擁塞，比如丟包時，就將慢啟動門限設為原來的一半，然后將擁塞窗口設置為1，開始執行慢啟動算法。（較低的起點，指數級增長）。
- 快速重傳： 假設發送方發送的報文段分別為： M1,M2,M3,M4,M5,M6 , 當接收方收到M1和M2后，M3報文段丟失，接著收到的M4，M5，M6都不做處理，而是沒接收到一個報文段就對M2重復確認，發送方接收到重復的三次確認報文段，就對其后的報文段進行重新發送，而不需要等待超時時間到達。當快速重傳后，立即進入到快速恢復階段。
- 快速恢復：將慢啟動門限設置為原來的一半，然后將擁塞窗口設置為現在的慢啟動門限值，不再執行慢啟動算法，而是直接進入擁塞避免階段。使發送窗口成線性方式增大。
TCP連接：
- ACK：確認序號有效。
- SYN：發起一個新連接。
- FIN：釋放一個連接。
握手(揮手)過程中必須有SYN(FIN)與ACK在同一次握手(揮手)當中傳輸，意味著確定打開(關閉)連接了。
TCP的三次握手：
- ack =?另一端發送的seq + 1
- seq = 另一端發送的ack
- 另一端沒有發送則建新值
第三次握手原因：
防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。
TCP的四次揮手：
揮手需要四次原因：
第二次只發送ACK，但是還不能發送FIN，因為服務端還有數據沒發完，所以在CLOSE-WAIT階段等待剩余數據的發送，發送完數據則發送ACK+FIN跟客戶端確定可以關閉連接了，進入LAST-ACK階段等待最后一次確定狀態，客戶端再發送一次ACK確定收到關閉連接消息，服務端就進入CLOSED。
客戶端在TIME-WAIT等待2MSL原因：
MSL指的是Maximum Segment Lifetime：一段TCP報文在傳輸過程中的最大生命周期。2MSL即是服務器端發出為FIN報文和客戶端發出的ACK確認報文所能保持有效的最大時長。
防止服務端沒有收到最后一次ACK，因為服務器端在1MSL內沒有收到客戶端發出的ACK確認報文，就會再次向客戶端發出FIN報文。
HTTP協議：
1.請求報文
- 請求行? ? ? ? ? ? ? ? ? ? 請求方法(Method)、URL字段和HTTP協議版本
- 請求頭? ? ? ? ? ? ? ? ? ? 存放對客戶端想給服務端的附加信息
- 請求體? ? ? ? ? ? ? ? ? ? 真正需要發給服務端的數據
2.響應報文
- HTTP是基于TCP的，客戶端往服務端發送一個HTTP請求時第一步就是要建立與服務端的TCP連接，也就是先三次握手
- socket層只是在TCP/UDP傳輸層上做的一個抽象接口層，因此一個socket連接可以基于TCP連接，也有可能基于UDP。
- HTTP采用“請求-響應”機制，在客戶端還沒發送消息給服務端前，服務端無法推送消息給客戶端。必須滿足客戶端發送消息在前，服務端回復在后。Socket連接雙方類似peer2peer的關系，一方隨時可以向另一方喊話。
get和post的區別
功能不同：
- get是從服務器上獲取數據。
- post是向服務器傳送數據。?
過程不同：
- 對于GET方式的請求，瀏覽器會把http header和data一并發送出去，服務器響應200（返回數據）；
- 而對于POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）。
傳送數據量不同
- get傳送的數據量較小，不能大于2KB。
- post傳送的數據量較大，一般被默認為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。?
安全性不同
- get安全性非常低。
- post安全性較高。?
對稱加密
- 客戶端和服務器共用同一個密鑰，該密鑰同時用于加密和解密一段內容。
- 對稱加密的優點是加解密效率高，但是在安全性方面可能存在一些問題，因為密鑰存放在客戶端有被竊取的風險。對稱加密的代表算法有：AES、DES等。
非對稱加密
- 將密鑰分成了兩種：公鑰和私鑰。
- 公鑰通常存放在客戶端，私鑰通常存放在服務器。
- 使用公鑰加密的數據只有用私鑰才能解密，反過來使用私鑰加密的數據也只有用公鑰才能解密。
- 非對稱加密的優點是安全性更高，因為客戶端發送給服務器的加密信息只有用服務器的私鑰才能解密，因此不用擔心被別人破解，但缺點是加解密的效率相比于對稱加密要差很多。非對稱加密的代表算法有：RSA、ElGamal等。
HTTP無狀態：
無狀態是指，當瀏覽器給服務器發送請求的時候，服務器響應客戶端請求。
但是當同一個瀏覽器再次發送請求給服務器的時候，服務器并不知道他就是剛才的那個瀏覽器。
簡單的說，就是服務器不會去記得你，所以就是http的無狀態協議。
保存用戶狀態的兩大機制：
HTTP與HTTPS：
- HTTP+SSL(Secure Sockets Layer?安全套接字協議),
- 傳統的http方式傳輸數據時信息都是明文的，數據很容易被監聽和竊取。傳輸的數據還有可能被一些別有用心的人篡改，導致瀏覽器與網站收發的內容不一致。
- HTTPS采用對稱加密+非對稱加密的方式
SSL協議的握手過程
瀏覽HTTPS網站過程：
瀏覽器隨機生成密鑰，然后用CA機構發的公鑰加密一層，傳輸到網站后，網站獲得密鑰。網站收到了瀏覽器隨機生成的密鑰之后，雙方就可以都使用對稱加密來進行通信了。
瀏覽器獲取網站的公鑰，以及保證公鑰的安全性由CA機構保證。
- CA機構則會使用網站管理員提交的公鑰，再加上一系列其他的信息，如網站域名、有效時長等，制作證書。
- 有瀏覽器請求網站時，首先會將這段加密數據返回給瀏覽器，此時瀏覽器會用CA機構的公鑰來對這段數據解密。
- 如果能解密成功，就可以得到CA機構給我們網站頒發的證書了，其中包括了網站的公鑰。
單向認證、雙向認證
單向認證指的是只有一個對象校驗對端的證書合法性。通常都是client來校驗服務器的合法性。那么client需要一個ca.crt,服器需要server.crt,server.key
雙向認證指的是相互校驗，服務器需要校驗每個client,client也需要校驗服務器。server 需要 server.key 、server.crt 、ca.crt。client 需要 client.key 、client.crt 、ca.crt。
?
總結
以上是生活随笔為你收集整理的Java—TCP与HTTP连接的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 推荐给开发人员的实用命令行工具
- 下一篇： Java—JVM的内存