TCP/IP

建立TCP需要三次握手才能建立（客戶端發起SYN,服務端SYN+ACK,客戶端ACK），

斷開連線則需要四次握手（客戶端和服務端都可以發起，FIN-ACK-FIN-ACK）。

為什麼連線的時候是三次握手，關閉的時候卻是四次握手？
答：因為當Server端收到Client端的SYN連線請求報文後，可以直接傳送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連線時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到Server端所有的報文都發送完了，我才能傳送FIN報文，因此不能一起傳送。故需要四步握手。

SYN攻擊：傳送大量的SYN,導致服務端無法識別哪些是有效的

RPC

RPC是指遠端呼叫，兩伺服器A,B，A要呼叫B上的一個方法，由於不在一個記憶體空間，不能直接呼叫，需要通過網路來表達呼叫的語義和傳達呼叫的資料

1.     通訊問題：在客戶端和服務端建立TCP連線，遠端呼叫的所有交換資料都在這個連線裡傳輸。

2.     解決定址問題：IP及埠定址，方法名

3.     序列化（Serialize）：發生遠端呼叫時，方法的引數需要通過底層的網路協議如TCP傳送到伺服器，由於網路協議是基於二進位制的，記憶體中的引數值需要序列化成二進位制的形式，通過定址和傳輸序列化的二進位制傳送給伺服器。

4.     伺服器反序列化：伺服器收到請求後需要反序列化，恢復記憶體中的表達方式，然後找到對應的方法（定址的一部分），進行本地呼叫。

5.     返回值傳送給客戶端，這個部分也需要序列化和反序列化。

SOA

採用一組服務的方式來構建一個應用，服務（hedwig、jsf、RESTful）獨立部署在不同的程序中，不同服務通過一些輕量級互動機制來通訊，例如RPC、HTTP等。服務可獨立擴充套件伸縮，每個服務定義了明確的邊界，不同的服務甚至可以採用不同的程式語言來實現，由獨立的團隊來維護。

RPC 的實現是基於SOA這樣的一個架構  C/S模式 遠端呼叫的通訊使用TCP  然後hedwig restful  jsf這些就是不同的服務形式

http協議和tcp/ip 協議的關係
(1) http是應用層協議，tcp協議是傳輸層協議，ip協議是網路協議。
(2) IP協議主要解決網路路由和定址問題
(3) tcp協議主要解決在IP層協議之上，如何可靠的傳輸資料，即接收端收到的資料包的大小和順序，和傳送端保持一致。tcp協議是可靠的面相連線的。

1.      http協議是無狀態的，指的是http協議對於事務處理沒有記憶功能，客戶端向服務端請求完資料之後，服務端不知道客戶端是什麼狀態。

2. http的長連線和短連線，本質上是tcp層的長連線和短連線：

http 1.0 預設使用短連線，http 1.1 預設使用長連線，在使用的http協議，在響應頭會加上 Connection:keep-alive

3. RPC比http請求快的原因：http使用http協議，rpc使用tcp協議，比http少了應用層，表示層，會話層，這3層，rpc使用長連線，而長連線比短連線更節省資源，效率更高（每個連線的建立和釋放都是需要資源和時間的）。

TCP/IP

是個協議組，可分為三個層次：網路層、傳輸層和應用層。

在網路層有IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議。

在傳輸層中有TCP協議與UDP協議。

在應用層有:TCP包括FTP、HTTP、TELNET、SMTP等協議

UDP包括DNS、TFTP等協議

當網路通訊時採用TCP協議時，在真正的讀寫操作之前，server與client之間必須建立一個連線，當讀寫操作完成後，雙方不再需要這個連線時它們可以釋放這個連線，連線的建立是需要三次握手的，而釋放則需要4次握手，所以說每個連線的建立都是需要資源消耗和時間消耗的。

通訊過程：

主機 A 的應用程式要能和主機 B 的應用程式通訊，必須通過 Socket 建立連線，而建立 Socket 連線必須需要底層 TCP/IP 協議來建立 TCP 連線。建立 TCP 連線需要底層 IP 協議來定址網路中的主機。我們知道網路層使用的 IP 協議可以幫助我們根據 IP 地址來找到目標主機，但是一臺主機上可能執行著多個應用程式，如何才能與指定的應用程式通訊就要通過 TCP 或 UPD 的地址也就是埠號來指定。這樣就可以通過一個 Socket 例項唯一代表一個主機上的一個應用程式的通訊鏈路了。

建立通訊鏈路

當客戶端要與服務端通訊，客戶端首先要建立一個 Socket 例項，作業系統將為這個 Socket 例項分配一個沒有被使用的本地埠號，並建立一個包含本地和遠端地址和埠號的套接字資料結構，這個資料結構將一直儲存在系統中直到這個連線關閉。在建立 Socket 例項的建構函式正確返回之前，將要進行 TCP 的三次握手協議，TCP 握手協議完成後，Socket 例項物件將建立完成，否則將丟擲 IOException 錯誤。

與之對應的服務端將建立一個 ServerSocket 例項，ServerSocket 建立比較簡單隻要指定的埠號沒有被佔用，一般例項建立都會成功，同時作業系統也會為 ServerSocket 例項建立一個底層資料結構，這個資料結構中包含指定監聽的埠號和包含監聽地址的萬用字元，通常情況下都是“*”即監聽所有地址。之後當呼叫 accept() 方法時，將進入阻塞狀態，等待客戶端的請求。當一個新的請求到來時，將為這個連線建立一個新的套接字資料結構，該套接字資料的資訊包含的地址和埠資訊正是請求源地址和埠。這個新建立的資料結構將會關聯到 ServerSocket 例項的一個未完成的連線資料結構列表中，注意這時服務端與之對應的 Socket 例項並沒有完成建立，而要等到與客戶端的三次握手完成後，這個服務端的Socket 例項才會返回，並將這個 Socket 例項對應的資料結構從未完成列表中移到已完成列表中。所以 ServerSocket 所關聯的列表中每個資料結構，都代表與一個客戶端的建立的TCP 連線。

TCP短連線

TCP短連線，client向server發起連線請求，server接到請求，然後雙方建立連線。client向server 傳送訊息，server迴應client，然後一次讀寫就完成了，這時候雙方任何一個都可以發起close操作，不過一般都是client先發起 close操作。因為一般的server不會回覆完client後立即關閉連線的，當然不排除有特殊的情況。從上面的描述看，短連線一般只會在client/server間傳遞一次讀寫操作。短連線的優點是：管理起來比較簡單，存在的連線都是有用的連線，不需要額外的控制手段。

TCP長連線

長連線，client向server發起連線，server接受client連線，雙方建立連線。Client與server完成一次讀寫之後，它們之間的連線並不會主動關閉，後續的讀寫操作會繼續使用這個連線。

TCP保活功能，保活功能主要為伺服器應用提供，伺服器應用希望知道客戶主機是否崩潰，從而可以代表客戶使用資 源。如果客戶已經消失，使得伺服器上保留一個半開放的連線，而伺服器又在等待來自客戶端的資料，則伺服器將應遠等待客戶端的資料，保活功能就是試圖在伺服器端檢測到這種半開放的連線。如果一個給定的連線在兩小時內沒有任何的動作，則伺服器就向客戶發一個探測報文段。客戶主機必須處於以下4個狀態之一：

1.客戶主機依然正常執行，並從伺服器可達。客戶的TCP響應正常，而伺服器也知道對方是正常的，伺服器在兩小時後將保活定時器復位。

2.客戶主機已經崩潰，並且關閉或者正在重新啟動。在任何一種情況下，客戶的TCP都沒有響應。服務端將不能收到對探測的響應，並在75秒後超時。伺服器總共傳送10個這樣的探測 ，每個間隔75秒。如果伺服器沒有收到一個響應，它就認為客戶主機已經關閉並終止連線。

3.客戶主機崩潰並已經重新啟動。伺服器將收到一個對其保活探測的響應，這個響應是一個復位，使得伺服器終止這個連線。

4.客戶機正常執行，但是伺服器不可達，這種情況與2類似，TCP能發現的就是沒有收到探查的響應。

從上面可以看出，TCP保活功能主要為探測長連線的存活狀況，不過這裡存在一個問題，存活功能的探測週期太長，還有就是它只是探測TCP連線的存活，屬於比較斯文的做法，遇到惡意的連線時，保活功能就不夠使了。

在長連線的應用場景下，client端一般不會主動關閉它們之間的連線，Client與server之間的連線如果一直不關閉的話，會存在一個問 題，隨著客戶端連線越來越多，server早晚有扛不住的時候，這時候server端需要採取一些策略，如關閉一些長時間沒有讀寫事件發生的連線，這樣可以避免一些惡意連線導致server端服務受損；如果條件再允許就可以以客戶端機器為顆粒度，限制每個客戶端的最大長連線數，這樣可以完全避免某個蛋疼的客戶端連累後端服務。

長連線和短連線的產生在於client和server採取的關閉策略，具體的應用場景採用具體的策略，沒有十全十美的選擇，只有合適的選擇。

HTTP長連線與短連線

長連線：client方與server方先建立連線，連線建立後不斷開，然後再進行報文傳送和接收。

這種方式下由於通訊連線一直存在。此種方式常用於P2P通訊。

短連線：Client方與server每進行一次報文收發交易時才進行通訊連線，交易完畢後立即斷開連線。

此方式常用於一點對多點通訊。C/S通訊。

長連線和短連線異同

長連線：長連線多用於操作頻繁，點對點的通訊，而且連線數不能太多的情況。

每個TCP連線的建立都需要三次握手，每個TCP連線的斷開要四次握手。

如果每次操作都要建立連線然後再操作的話處理速度會降低，所以每次操作後，下次操作時直接傳送資料就可以了，不用再建立TCP連線。例如：資料庫的連線用長連線，如果用短連線頻繁的通訊會造成socket錯誤，頻繁的socket建立也是對資源的浪費。

短連線：web網站的http服務一般都用短連線。因為長連線對於伺服器來說要耗費一定的資源。像web網站這麼頻繁的成千上萬甚至上億客戶端的連線用短連線更省一些資源。試想如果都用長連線，而且同時用成千上萬的使用者，每個使用者都佔有一個連線的話，可想而知伺服器的壓力有多大。所以併發量大，但是每個使用者又不需頻繁操作的情況下需要短連線。

傳送接收方式

1、非同步：報文傳送和接收是分開的，相互獨立，互不影響的。這種方式又分兩種情況：

非同步雙工：接收和傳送在同一個程式中，有兩個不同的子程序分別負責傳送和接送。

非同步單工：接送和傳送使用兩個不同的程式來完成。

2、同步：報文傳送和接收是同步進行，即報文傳送後等待接送返回報文。同步方式一般需要考慮超時問題，試想我們傳送報文以後也不能無限等待啊，所以我們要設定一個等待時候。超過等待時間傳送方不再等待讀返回報文。直接通知超時返回。

阻塞與非阻塞方式

1、非阻塞方式：讀函式不停的進行讀動作，如果沒有報文接收到，等待一段時間後超時返回，這種情況一般需要指定超時時間。

2、阻塞方式：如果沒有接收到報文，則讀函式一直處於等待狀態，知道報文到達。

及時通訊與遊戲的長短連線

實際場合究竟需要使用短連線還是長連線，主要看實時性要求、資料流向和併發量這三個問題。

長連線優點：節約TCP握手時間，可以保證高實時性，資料流向可以採用伺服器端的主動推模式。
長連線缺點：併發量不宜太高，持續佔用服務埠（相對消耗資源）。

長連線、長輪詢一般應用與WebIM、ChatRoom和一些需要及時互動的網站應用中。其真實案例有：WebQQ、Hi網頁版、Facebook IM等。

1.現在遊戲中的玩家與玩家之間的聊天無法實現實時性，而且系統有郵件或資訊時也不能及時的通知玩家
—— 如果涉及到聊天的話，一般來說還是用長連線會更合適，否則大量時間浪費到握手上了；
—— 但是手機的網路長連線網路質量可能會比較撮，你需要嚴重考慮容錯和重鏈機制。

2.客戶端每隔幾秒就會發送一個請求，這樣伺服器的壓力豈不是很大？
—— 壓力會比較大，關鍵是聊天往往對時間的要求很高，如果是團戰的話，1秒內沒看到資訊，可能就會覺得完全受不了了；當然也看你聊天的場景如何，是群聊還是單聊，以後會不會發展為語音啥的；

NIO沒有任何問題，大規模長連線處理的主流都是用NIO；而且也不是Java發明的，本身就是藉助了作業系統的網路管理能力。

http keep-alive與tcp keep-alive，不是同一回事，意圖不一樣。http keep-alive是為了讓tcp活得更久一點，以便在同一個連線上傳送多個http，提高socket的效率。而tcp keep-alive是TCP的一種檢測TCP連線狀況的保鮮機制