Java Socket Streams是否安全？

Question

我使用java Sockets和ServerSockets來連接多個設備。 Socket的OutputStream發送的部分數據是否沒有到達對方的InputStream的風險？

Answer 1

沒有保證。如果網絡出現故障，您的數據將永遠不會到達那裏。除非網絡出現故障，否則如果您使用的是TCP，並且您正在以線程安全的方式使用套接字流，並且確信已從套接字的OutputStream中刷新了數據，則可以保證您的數據將顯示出來。另一方面，UDP沒有這樣的保證。

Answer 2

傳輸控制協議（TCP）在IP之上運行，並在發送方和接收方之間提供面向連接的服務。 TCP提供有保證的交付並確保數據包按順序交付。底層網絡IP非常不可靠，並且不爲TCP提供任何保證。爲了提供發送方和接收方之間的可靠性，TCP使用各種機制，如序列號，確認，三方握手和定時器。

通過這樣做，發件人和收件人可以驗證數據是否正確傳遞。他們還可以確定數據是否被丟棄，可能是因爲運輸中的損失。

發送方和接收方都在連接設置階段交換初始序列號（ISN）。首次握手成功後，發送方和接收方都知道它們必須用於通信的序列號。由於TCP允許延遲段，因此它必須接受不符合順序的段，但在一定範圍內（稱爲接收器窗口大小）。接收器窗口大小在初始握手期間也被交換。 TCP將放棄在計算範圍內沒有序號的所有段。

序列號 TCP序列號是一個32位計數器。爲了區分同一發送者和接收者之間的不同連接，重要的是，每次打開連接時，序列號不會從0開始或者以任何其他固定的數字開始。因此，從發送方到接收方的數據的第一個字節使用隨機序列號非常重要。當前的實現每秒將有限數量的序列號遞增。

三次握手 TCP使用三次握手建立成功的連接。當主機A想要打開與主機B的連接時，A向B發送初始段。該初始段具有B需要用來向A發送數據的初始序列號（ISN）。該初始段由SYN標識在TCP報頭中設置爲1。如果設置了SYN位，則頭中的32位序列號被解釋爲ISN。在所有其他情況下（當SYN位未置位時），32位序列號標識該段中包含的第一個數據字節的序列號。 B在接收來自A的SYN時，必須用另一個SYN作出響應，並且確認由A發送的SYN。這在狀態機圖中由SYN + ACK表示。

定時器

定時器與TCP狀態嚴密。

連接建立計時器 該計時器與打開連接關聯。它在初始連接設置期間發送SYN時啓動。在大多數TCP實現中，此計時器的值設置爲75秒。如果發生超時，連接將中止。當存在從FIN_WAIT_1狀態到FIN_WAIT_2狀態的轉變

FIN_WAIT計時器
甲FIN_WAIT_2啓動計時器。這個計時器的值是10分鐘。預期在FIN_WAIT_2狀態下具有FIN位設置的TCP段。如果接收到FIN位的數據包，定時器將被取消。在計時器到期時，它將以75秒的值重新啓動。如果在此期間沒有FIN位的數據包到達，連接將被丟棄。

TIME_WAIT定時器
當連接進入TIME-WAIT狀態的時間等待計時器開始計時。這是爲了允許從網絡中移除所有傳輸段。定時器的值通常設置爲2分鐘。計時器到期時，連接終止。

KEEP_ALIVE計時器 如果沒有要發送的數據，TCP通常不會在連接上發送任何內容。當連接斷開時，沒有辦法區分這種沉默。可以設置保活計時器，它允許TCP定期檢查連接的另一端是否仍處於活動狀態。此計時器的默認值是2小時。定時器到期後，探測器被髮送到遠端。如果遠程沒有響應探針，連接將被丟棄。

詳情refer to this link

Answer 3

我以爲你是問有關正插座;例如TCP/IP流。

一般來說，TCP會檢測丟失和損壞的數據包並導致它們被重新傳輸。它也將處理亂序傳送的數據包。假設這些機制起作用，則寫入輸出流的每個字節都可以從相應的輸入流中讀取。然而，它並不總是工作：

1. 如果在網絡上長時間中斷，則存在一種風險，即連接的一端會超時的另一端，並接收的所有數據之前斷開連接。

2. TCP使用16位數據包級校驗和來防止數據在實踐中被破壞。校驗和不會檢測到隨機數據包損壞的可能性很小。最終的結果將是錯誤的數據到達。

3. 有些方法可能會干擾建立的TCP/IP連接（例如通過注入具有欺騙源地址的數據包）。這可能會過早地破壞連接，或者更糟。

如果您在詢問DatagramSockets，那麼（例如）任何UDP/IP數據報都可能丟失。不保證會收到任何發送的數據。