Kết nối nửa mở TCP là gì và kết nối nửa kín TCP là gì

Tôi đang cố gắng hiểu sự khác biệt giữa TCP Half Open Connection và TCP Half kín có ai có thể nói chính xác chúng là gì không?

Bài đăng này mở rộng trên một nửa kết nối kín. Đối với một nửa kết nối mở, xem mô tả chính xác của KContreau.

Một nửa kết nối kín là gì? Hoặc: Đó không phải là một lỗi - đó là một tính năng!

Mỗi kết nối TCP bao gồm hai nửa kết nối được đóng độc lập với nhau. Vì vậy, nếu một đầu gửi FIN, thì đầu kia sẽ tự do chỉ ACK mà FIN (thay vì FIN + ACK-ing nó), báo hiệu kết thúc gửi FIN mà nó vẫn có dữ liệu để gửi. Vì vậy, cả hai đầu cuối đều ở trạng thái truyền dữ liệu ổn định khác với ESTABOUNDED - cụ thể là FIN_WAIT_2 (cho đầu nhận) và CLOSE_WAIT (cho đầu gửi). Một kết nối như vậy được cho là đóng một nửa và TCP thực sự được thiết kế để hỗ trợ các kịch bản đó, vì vậy một nửa kết nối đóng là một tính năng TCP.

Lịch sử của một nửa kết nối

Trong khi RFC 793 chỉ mô tả cơ chế thô mà không đề cập đến thuật ngữ "nửa kín", RFC 1122 giải thích chi tiết về vấn đề đó trong mục 4.2.2.13. Bạn có thể tự hỏi ai là địa ngục cần tính năng đó. Các nhà thiết kế của TCP cũng đã triển khai TCP / IP cho hệ thống Unix và, giống như mọi người dùng Unix, yêu thích chuyển hướng I / O. Theo W. Stevens (TCP / IP được minh họa, Phần 18.5) mong muốn các luồng TCP chuyển hướng I / O là động lực để giới thiệu tính năng này. Nó cho phép FIN ack đảm nhận vai trò hoặc được dịch là EOF. Vì vậy, về cơ bản, đây là một tính năng cho phép bạn tình cờ tạo ra tương tác kiểu yêu cầu / phản hồi ngẫu hứng trên lớp ứng dụng, nơi FIN báo hiệu "kết thúc yêu cầu".

Khi TCP thiết lập kết nối, nó được coi là đảm bảo vì có một cái bắt tay diễn ra:

1. Máy tính khởi tạo gửi yêu cầu Kết nối, gửi một SYN
2. Máy tính phản hồi cấp yêu cầu, trả lời với một SYN-ACK
3. Máy tính khởi tạo gửi xác nhận, trả lời bằng ACK

Tại thời điểm đó, kết nối được thiết lập và dữ liệu bắt đầu chảy. Ngược lại, một gói UDP không được bảo đảm và chỉ được gửi với hy vọng nó sẽ đến đó.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_est Thiết lập

Chính thức, theo RFC, kết nối TCP mở một nửa là khi một bên của kết nối được thiết lập bị hỏng và không gửi thông báo rằng kết nối đã kết thúc. Đây không phải là cách sử dụng phổ biến hiện nay.

Không chính thức, nếu có thể đề cập đến một kết nối phôi, đó là một kết nối trong quá trình được thiết lập.

http://en.wikipedia.org/wiki/Embryonic_connection

Nửa kín là trái ngược với định nghĩa không chính thức đó. Đó là một trạng thái ở đâu đó ở giữa nơi các máy tính đang phá hỏng kết nối đã được thiết lập.

Những người khác đã làm một công việc khá tốt khi mô tả các kết nối nửa mở và nửa kín thực sự là gì , nhưng ý tưởng về các kết nối nửa mở cũng thường được tìm kiếm trong bối cảnh chúng là một VẤN ĐỀ.

Có nhiều tranh luận trên internet về thuật ngữ "nửa mở" hay "nửa kín" nên đại diện cho điều gì, nhưng theo tôi nghĩ, thuật ngữ chỉ là ngữ nghĩa. Một số người nói rằng các kết nối "nửa mở" là một "vấn đề", trong khi "nửa kín" là một tính năng thiết kế cho phép bạn đóng luồng gửi của mình bằng cách đóng luồng gửi trước khi quá trình tải xuống tệp của bạn kết thúc ở trạng thái nửa kín ( như những người dùng khác mô tả).

Tuy nhiên, liên quan đến ... "vấn đề" khác: phải bắt tay 3 bước để mở kết nối TCP và bắt tay 4 chiều để đóng nó.

TCP có một lỗ hổng trong đó gói FIN cuối cùng được gửi đến máy khách có thể bị các bộ định tuyến / mạng bỏ rơi dẫn đến kết nối bị mở một nửa khi ý định thực sự là đóng hoàn toàn kết nối. Cách tiếp cận tương tự này là các kiểu tấn công từ chối dịch vụ phổ biến vì chúng không đòi hỏi nhiều băng thông, nhưng có khả năng ăn hết các tay cầm, ổ cắm và luồng có giá trị tùy thuộc vào việc triển khai máy chủ, nhưng chúng cũng có thể xảy ra trong thế giới thực với tần suất ngày càng tăng nhờ các nhà mạng không dây kém chất lượng của chúng tôi.

Các hệ điều hành đã cố gắng chống lại các cuộc tấn công DDoS nửa mở bằng cách giới hạn số lượng kết nối nửa mở / đóng có thể có trong hệ điều hành tại một thời điểm nhất định và bằng cách đưa ra thời gian tối đa mà các kết nối có thể duy trì trong một trạng thái nửa mở / đóng. Cá nhân tôi đã kiểm tra lần cuối, tuy nhiên, giới hạn thời gian trên Windows là khá cao (2 ngày, nếu tôi nhớ lại).

Điều kiện này càng trở nên trầm trọng hơn bởi bản chất tùy chọn của các bộ giữ TCP, mà nếu được thực hiện đầy đủ được dùng như một giải pháp ở cấp độ giao thức (trái ngược với cấp độ ứng dụng) để phát hiện các kết nối chết / zombie. Nhưng, khi TCP được thiết kế, băng thông quý hơn đáng kể so với hiện tại và có những lo ngại rằng bộ định thời duy trì bắt buộc cho TCP sẽ quá "chát". Do đó, các khoản giữ là tùy chọn, thường không được sử dụng và không được bảo đảm để được truyền bởi các bộ định tuyến theo RFC1122. Vì vậy, ... ngay cả khi bạn kích hoạt tính năng giữ lại ở lớp TCP trong nỗ lực phát hiện / xử lý tình huống, bạn có thể thấy rằng khi lưu lượng truy cập của mình đi khắp thế giới, một số bộ định tuyến đang bỏ các gói giữ ... có khả năng KHÁC kịch bản hiếm để thử nghiệm.

Các kết nối nửa mở đặt ra một chút thách thức kỹ thuật đối với các lập trình viên viết các máy chủ dựa trên TCP, đặc biệt, bởi vì chúng có thể vô tình xuất hiện ngẫu nhiên, trong thời gian tải cao ... và thường là trên các máy chủ sản xuất ... và có thể khó nhận thấy trong các giai đoạn thử nghiệm Alpha / Beta. Theo kinh nghiệm của tôi, tôi thấy chúng xảy ra ở khoảng 1 trong 40.000 kết nối trên các máy chủ xử lý 2,5 triệu kết nối / ngày, nhưng những con số đó sẽ thay đổi tùy thuộc vào điều kiện lưu lượng của bạn và điều kiện lưu lượng của mọi chặng internet giữa máy chủ của bạn và máy khách .

Là một kỹ sư, có thể khó theo dõi các sự cố xảy ra không thường xuyên và chỉ trên các máy chủ được triển khai trực tiếp, do đó, điều quan trọng là phải thử mô phỏng trạng thái kết nối hiếm gặp này khi viết mã máy chủ TCP để phân tích cách máy chủ của bạn sẽ phản ứng khi Đối mặt với tình huống này. Ví dụ, nếu máy chủ TCP của bạn sử dụng một số luồng công nhân tĩnh, bạn có thể tìm thấy tất cả chúng được tiêu thụ bởi các kết nối zombie khi bạn triển khai vào sản xuất, chẳng hạn. Nếu các kết nối yêu cầu nhiều bộ nhớ làm việc, thì kết quả cuối cùng có thể xuất hiện tương tự như rò rỉ bộ nhớ. Vân vân.

Nếu không có giải pháp duy trì khả thi 100%, TCP sẽ đưa nó đến tầng người dùng để xác định cách xử lý các kết nối nửa mở / đóng, do đó mã của bạn phải có kế hoạch / cơ chế để phát hiện, hết thời gian và làm sạch tăng tài nguyên khi điều kiện này xảy ra ... đó là ... giả sử rằng đây là giao thức bạn đã phát minh và không phải là một trong nhiều tiêu chuẩn mở (xấu) mà các lập trình viên thường sử dụng. Tất nhiên tôi đang đề cập đến các giao thức như HTTP, chỉ chạy trên TCP. Các giao thức này được đánh giá rất cao theo ý kiến ​​của lập trình viên này.

Nhận thấy những điểm yếu của TCP và sự phổ biến đáng tiếc của nó khi truyền lưu lượng HTTP / Web, các công ty thông minh đã tìm cách tìm kiếm một sự thay thế. Ví dụ: Google đã thử nghiệm một giao thức có tên QUIC, truyền HTTP qua UDP. Ngoài ra còn có một giao thức mở gọi là TSCP. Không ai trong số các giao thức đã thấy áp dụng rộng rãi tuy nhiên.

Theo quy định, tôi xây dựng tất cả các máy chủ của riêng mình để nói chuyện riêng trên giao thức dựa trên UDP của riêng tôi. Tuy nhiên, UDP phức tạp hơn bạn nghĩ và tôi cảm thấy như mình luôn điều chỉnh nó để nhanh hơn, thông minh hơn, độ trễ thấp hơn, tắc nghẽn thấp hơn ... nhưng ít nhất tôi không còn phải xử lý các kết nối nửa mở; )

Giải thích tốt nhất về chấm dứt kết nối TCP

Trong Quá trình bắt tay 3 bước TCP, chúng tôi đã nghiên cứu cách thiết lập kết nối giữa máy khách và máy chủ trong Giao thức điều khiển truyền (TCP) bằng cách sử dụng các phân đoạn bit SYN. Trong bài viết này, chúng tôi sẽ nghiên cứu về cách TCP kết nối chặt chẽ giữa Máy khách và Máy chủ. Ở đây chúng ta cũng sẽ cần gửi các phân đoạn bit đến máy chủ mà bit FIN được đặt thành 1.

11

Cách cơ chế hoạt động trong TCP:

Step 1 (FIN From Client) – Suppose that the client application decides it wants to close the connection. (Note that the server could also choose to close the connection). This causes the client send a TCP segment with the FIN bit set to 1 to server and to enter the FIN_WAIT_1 state. While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment (ACK).
Step 2 (ACK From Server) – When Server received FIN bit segment from Sender (Client), Server Immediately send acknowledgement (ACK) segment to the Sender (Client).
Step 3 (Client waiting) – While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment. When it receives this segment, the client enters the FIN_WAIT_2 state. While in the FIN_WAIT_2 state, the client waits for another segment from the server with the FIN bit set to 1.
Step 4 (FIN from Server) – Server sends FIN bit segment to the Sender(Client) after some time when Server send the ACK segment (because of some closing process in the Server).
Step 5 (ACK from Client) – When Client receive FIN bit segment from the Server, the client acknowledges the server’s segment and enters the TIME_WAIT state. The TIME_WAIT state lets the client resend the final acknowledgment in case the ACK is lost.The time spent by client in the TIME_WAIT state is depend on their implementation, but their typical values are 30 seconds, 1 minute, and 2 minutes. After the wait, the connection formally closes and all resources on the client side (including port numbers and buffer data) are released.

thêm về: https://www.geekforgeek.org/tcp-connection-termination/

Kết nối nửa kín là một quá trình được thiết lập khi một đầu của máy chủ và Máy khách có ý định chấm dứt kết nối. TCP là một quá trình hướng kết nối, do đó mỗi ổ cắm được mở cho một ứng dụng cụ thể. Trong TCP không có áp lực để chấm dứt ứng dụng. Do đó, quá trình định hướng kết nối kéo dài thời gian kết thúc với tín hiệu chờ. điều này được gọi là đóng một nửa trong TCP (kết nối)