apa itu TCP Half Open Connection dan TCP half closed connection

Saya mencoba memahami apa perbedaan antara TCP Half Open Connection dan TCP Half closed connection dapatkah ada yang tahu apa sebenarnya mereka?

Posting ini diperluas pada koneksi setengah tertutup. Untuk setengah koneksi terbuka lihat deskripsi yang benar dari KContreau.

Apa itu Koneksi Setengah Tertutup? Atau: Ini Bukan Bug - ini Fitur!

Setiap koneksi TCP terdiri dari dua koneksi setengah yang ditutup secara independen satu sama lain. Jadi, jika salah satu ujung mengirimkan FIN, maka ujung lainnya bebas untuk hanya ACK FIN itu (bukan FIN + ACK-ing itu), yang menandakan akhir pengiriman FIN bahwa ia masih memiliki data untuk dikirim. Jadi kedua ujungnya berakhir dalam keadaan transfer data yang stabil selain dari ESTABLISHED - yaitu FIN_WAIT_2 (untuk pihak penerima) dan CLOSE_WAIT (untuk tujuan pengiriman). Koneksi semacam itu dikatakan setengah tertutup dan TCP sebenarnya dirancang untuk mendukung skenario tersebut, sehingga koneksi setengah tertutup adalah fitur TCP.

Sejarah Koneksi Setengah Tertutup

Sementara RFC 793 hanya menjelaskan mekanisme mentah tanpa menyebutkan istilah "setengah tertutup", RFC 1122 menguraikan hal itu di bagian 4.2.2.13. Anda mungkin bertanya-tanya siapa yang membutuhkan fitur itu. Perancang TCP juga menerapkan TCP / IP untuk sistem Unix dan, seperti setiap pengguna Unix, menyukai pengalihan I / O. Menurut W. Stevens (TCP / IP diilustrasikan, Bagian 18.5) keinginan untuk I / O-redirect stream TCP adalah motivasi untuk memperkenalkan fitur. Hal ini memungkinkan FIN ack mengambil peran atau diterjemahkan sebagai EOF. Jadi pada dasarnya ini adalah fitur yang memungkinkan Anda untuk dengan santai membuat interaksi permintaan / respons-gaya dadakan pada lapisan aplikasi, di mana FIN memberi sinyal "akhir permintaan".

Ketika TCP membuat koneksi, itu dianggap dijamin karena ada jabat tangan yang terjadi:

1. Komputer yang memulai mengirim permintaan Koneksi, mengirimkan SYN
2. Komputer yang merespons memberikan permintaan, membalas dengan SYN-ACK
3. Komputer yang memulai mengirim pemberitahuan, menjawab dengan ACK

Pada titik itu koneksi dibuat, dan data mulai mengalir. Sebaliknya, paket UDP tidak dijamin, dan hanya dikirim dengan harapan akan ada di sana.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment

Secara resmi, menurut RFC, koneksi TCP setengah terbuka adalah ketika salah satu sisi koneksi yang dibuat telah macet, dan tidak mengirim pemberitahuan bahwa koneksi berakhir. Ini bukan penggunaan umum hari ini.

Secara tidak resmi, jika bisa merujuk ke koneksi embrionik, yang merupakan koneksi dalam proses pembentukan.

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

Setengah tertutup adalah kebalikan dari definisi tidak resmi itu. Ini adalah kondisi di suatu tempat di tengah di mana komputer menghancurkan koneksi yang sudah ada.

Orang-orang lain melakukan pekerjaan yang cukup layak untuk menggambarkan apa koneksi setengah terbuka dan setengah tertutup sebenarnya adalah , tapi ide koneksi yang setengah terbuka juga sering dicari dalam konteks mereka menjadi MASALAH a.

Ada beberapa argumen di internet tentang apa yang harus diwakilkan oleh istilah "setengah terbuka" atau "setengah tertutup", tetapi sejauh yang saya ketahui, terminologi hanyalah semantik. Beberapa mengatakan bahwa koneksi "setengah terbuka" adalah "masalah", sementara "setengah tertutup" adalah fitur desain yang memungkinkan Anda untuk menutup aliran pengiriman dengan menutup aliran pengiriman sebelum pengunduhan file selesai dalam keadaan setengah tertutup ( seperti yang dijelaskan pengguna lain).

Namun, mengenai yang lain ... "masalah": dibutuhkan jabat tangan 3 cara untuk membuka koneksi TCP dan jabat tangan 4 arah untuk menutupnya.

TCP memiliki kerentanan di mana paket FIN final yang dikirim ke klien dapat berpotensi dijatuhkan oleh router / jaringan yang menghasilkan koneksi yang setengah terbuka ketika niat sebenarnya adalah untuk sepenuhnya menutup koneksi. Ini dan pendekatan yang serupa telah menjadi jenis serangan Denial of Service yang populer karena mereka tidak memerlukan banyak bandwidth, namun berpotensi memakan gagang, soket, dan utas yang berharga tergantung pada implementasi server, tetapi mereka juga dapat terjadi di dunia nyata dengan peningkatan frekuensi berkat operator nirkabel jelek kami.

Sistem operasi telah melakukan upaya untuk melawan serangan DDoS setengah terbuka dengan membatasi jumlah koneksi setengah terbuka / tertutup yang dapat hadir dalam sistem operasi pada waktu tertentu dan dengan memperkenalkan jangka waktu maksimum bahwa koneksi dapat tetap dalam kondisi setengah terbuka / tertutup. Terakhir saya periksa, secara pribadi, bagaimanapun, batas waktu pada Windows cukup tinggi (2 hari, jika saya ingat).

Kondisi ini semakin diperburuk oleh sifat opsional dari TCP keep-alives, yang jika diimplementasikan sepenuhnya dimaksudkan sebagai solusi tingkat protokol (sebagai lawan tingkat aplikasi) untuk mendeteksi koneksi zombie / mati. Tapi, ketika TCP dirancang, bandwidth jauh lebih berharga daripada sekarang, dan ada kekhawatiran bahwa penghitung waktu yang tetap untuk TCP akan terlalu "cerewet". Oleh karena itu keep-alive bersifat opsional, tidak umum digunakan, dan tidak dijamin ditransmisikan oleh router menurut RFC1122. Jadi ... bahkan jika Anda mengaktifkan keep-alive di layer TCP dalam upaya untuk mendeteksi / menangani skenario, Anda mungkin menemukan bahwa ketika lalu lintas Anda bepergian ke seluruh dunia, beberapa router menjatuhkan paket keep-live ... menciptakan Skenario langka yang berpotensi LAIN untuk diuji.

Koneksi setengah terbuka menimbulkan sedikit tantangan teknis bagi pembuat kode yang menulis server berbasis TCP, khususnya, karena mereka dapat secara tidak sengaja muncul secara acak, selama waktu beban tinggi ... dan biasanya pada server produksi ... dan dapat sulit untuk diperhatikan dalam tahap pengujian Alpha / Beta. Dalam pengalaman saya, saya menemukan mereka terjadi di mungkin 1 dari 40.000 koneksi pada server yang menangani 2,5 juta koneksi / hari, tetapi angka-angka itu akan bervariasi tergantung pada kondisi lalu lintas Anda dan kondisi lalu lintas setiap kaki internet antara server Anda dan klien .

Sebagai seorang insinyur, mungkin sulit untuk melacak masalah yang jarang terjadi dan hanya pada server yang ditempatkan langsung, sehingga penting untuk mencoba mensimulasikan kondisi koneksi langka ini ketika menulis kode server TCP untuk menganalisis bagaimana server Anda akan bereaksi ketika Menghadapi situasi ini. Misalnya, jika server TCP Anda menggunakan jumlah pekerja-utas yang statis, Anda mungkin mendapati semuanya dikonsumsi oleh koneksi zombie saat Anda menggunakan produksi, misalnya. Jika koneksi memerlukan banyak memori yang berfungsi, maka hasil akhirnya bisa tampak mirip dengan kebocoran memori. dll. dll

Tanpa 100% solusi keep-live yang layak, TCP menyerahkannya ke lapisan pengguna untuk menentukan bagaimana koneksi setengah terbuka / tertutup ditangani, sehingga kode Anda harus memiliki rencana / mekanisme untuk mendeteksi, time-out, dan pembersihan. sumber daya ketika kondisi ini terjadi ... yaitu ... dengan asumsi bahwa ini adalah protokol yang Anda buat dan bukan salah satu dari banyak standar terbuka (buruk) yang biasanya digunakan oleh pemrogram. Tentu saja saya mengacu pada protokol seperti HTTP, yang berjalan secara eksklusif melalui TCP. Protokol-protokol ini sangat berlebihan menurut pendapat programmer ini.

Menyadari kelemahan TCP dan popularitasnya yang tidak menguntungkan untuk mentransmisikan lalu lintas HTTP / Web, perusahaan-perusahaan pintar telah berupaya mencari penggantinya. Misalnya, Google bereksperimen dengan protokol yang disebut QUIC, yang mentransmisikan HTTP melalui UDP. Ada juga protokol terbuka yang disebut TSCP. Namun tidak satu pun dari protokol-protokol tersebut yang melihat adopsi luas.

Sebagai aturan, saya membangun semua server saya sendiri untuk berbicara secara eksklusif pada protokol berbasis UDP saya sendiri. Namun, UDP lebih sulit dari yang Anda kira, dan saya merasa saya selalu mengubahnya agar lebih cepat, lebih cerdas, latensi rendah, kemacetan lebih rendah ... tetapi setidaknya saya tidak lagi harus berurusan dengan koneksi setengah terbuka; )

Penjelasan terbaik tentang Pemutusan Koneksi TCP

Dalam TCP 3-way Handshake Process kami mempelajari bahwa bagaimana koneksi membangun antara klien dan server dalam Transmission Control Protocol (TCP) menggunakan segmen bit SYN. Pada artikel ini kita akan mempelajari tentang bagaimana TCP menutup koneksi antara Client dan Server. Di sini kita juga perlu mengirim segmen bit ke server yang FIN bit diatur ke 1.

11

Bagaimana mekanisme bekerja di 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.

lebih lanjut tentang: https://www.geeksforgeeks.org/tcp-connection-termination/

Koneksi setengah tertutup adalah proses yang dibuat ketika salah satu ujung server dan Klien bermaksud untuk mengakhiri koneksi. TCP adalah proses yang berorientasi koneksi sehingga setiap soket dibuka untuk aplikasi tertentu. Dalam TCP tidak ada tekanan untuk menghentikan aplikasi. Dengan demikian proses yang berorientasi koneksi memperpanjang pemutusan dengan sinyal tunggu. ini disebut setengah tertutup dalam TCP (koneksi)