Ukuran paket maksimum untuk koneksi TCP

196

Berapa ukuran paket maksimum untuk koneksi TCP atau bagaimana saya bisa mendapatkan ukuran paket maksimum?

networking  tcp 
— Alexa
sumber
24
TCP berbasis aliran. Apakah ada alasan khusus Anda khawatir tentang paket individual?
— Matti Virkkunen
27
Karena lapisan di bawahnya adalah berbasis paket ... Implementasi Khas -> Lapisan 1 - Ethernet PHY, Lapisan 2 - Ethernet MAC (Definisi Paket MAC, Layer 3 - Protokol Internet (Definisi Paket IP), Layer 4 - TCP (Protokol Kontrol Transmisi ) - Menggunakan layanan berbasis paket di bawahnya
2
Tidak ada yang namanya 'paket TCP'. Ada segmen TCP , yang panjangnya dijelaskan oleh kata 32-bit, dan mereka terkandung dalam atau di seluruh paket IP , yang panjangnya dijelaskan dalam 16 bit. Ada juga frame Ethernet, yang berisi semua hal ini. Manakah dari hal-hal ini yang Anda tanyakan? Dalam kasus apa pun jika Anda menggunakan TCP, Anda tidak perlu khawatir tentang mereka dengan cara apa pun: TCP dan IP menjaga semuanya untuk Anda.
— Marquis of Lorne

Jawaban:

178

Batasan absolut pada ukuran paket TCP adalah 64K (65535 byte), tetapi dalam praktiknya ini jauh lebih besar dari ukuran paket apa pun yang akan Anda lihat, karena lapisan bawah (misalnya ethernet) memiliki ukuran paket yang lebih rendah.

MTU (Maximum Transmission Unit) untuk Ethernet, misalnya, adalah 1500 byte. Beberapa jenis jaringan (seperti Token Ring) memiliki MTU yang lebih besar, dan beberapa jenis memiliki MTU yang lebih kecil, tetapi nilainya tetap untuk setiap teknologi fisik.

— Eter
sumber
15
"Tapi nilainya tetap untuk setiap teknologi fisik" - ini tidak benar. Dulu Ethernet memiliki MTU maksimum 1500, tetapi Anda bisa menggunakan yang lebih rendah. Dengan munculnya bingkai jumbo, tidak ada maksimum yang ditentukan nyata, dan maksimum bervariasi tergantung pada perangkat keras dan driver.
— Angin puyuh
4
@ Whirl: true, mereka dapat dikonfigurasi, tetapi umumnya mereka tidak; "dapat dikonfigurasi" bersifat subyektif karena kita harus menyelidiki kernel untuk melakukannya. Ini bukan sesuatu yang bisa diutak-atik di tingkat aplikasi, di situlah OP berada.
— Eter
3
@HiroProtagonist: 1500 adalah maksimum, jadi memiliki 600 tidaklah mengejutkan.
— Nicolas Raoul
28
mengapa 64K (65535 byte) batasannya? Karena atribut Window Size dalam TCP Header hanya 16 bit. Saya hanya ingin menyebutkan, kadang-kadang bisa membantu seseorang ..... jawaban yang bagus btw @ Lainnya!
— Cacho Santa
2
Juga, dimungkinkan untuk meningkatkannya dengan menggunakan penskalaan jendela. Dalam hal ini maksimum adalah 1 GiB
— Martin Melka
86

Ini adalah pertanyaan yang sangat bagus dan saya sering mengalami hal ini di tempat kerja. Ada banyak jawaban "benar secara teknis" seperti 65k dan 1500. Saya telah melakukan banyak pekerjaan menulis antarmuka jaringan dan menggunakan 65k adalah konyol, dan 1500 juga dapat membawa Anda ke masalah besar. Pekerjaan saya berjalan pada banyak perangkat keras / platform / router yang berbeda, dan jujur ​​saja tempat saya mulai adalah 1400 byte. Jika Anda MEMBUTUHKAN lebih dari 1400 Anda dapat mulai naik, Anda mungkin bisa pergi ke 1450 dan kadang-kadang ke 1480'ish? Jika Anda membutuhkan lebih dari itu maka tentu saja Anda perlu membaginya menjadi 2 paket, di mana ada beberapa cara yang jelas untuk dilakukan ..

Masalahnya adalah bahwa Anda sedang berbicara tentang membuat paket data dan menuliskannya melalui TCP, tapi tentu saja ada data header yang ditempelkan dan sebagainya, sehingga Anda memiliki "bagasi" yang menempatkan Anda ke 1500 atau lebih .. dan juga Banyak perangkat keras memiliki batas yang lebih rendah.

Jika Anda "mendorongnya", Anda bisa mendapatkan beberapa hal aneh yang terjadi. Data terpotong, jelas, atau data yang dijatuhkan jarang saya lihat. Data yang rusak juga jarang tetapi pasti memang terjadi.

— Nektarios
sumber
Mengapa permintaan GET rata-rata sekitar 600 Bytes?
10
Maksud Anda 64K, bukan 65K. Saya tidak tahu apa yang Anda maksud dengan 'tempat saya mulai adalah 1400 byte'. Anda tidak perlu khawatir tentang ukuran paket di TCP API. Ini mengurus menentukan dan mengamati jalur MTU. Tidak ada alasan mengapa Anda tidak dapat menulis 2G dalam satu send()jika itu nyaman.
— Marquis of Lorne
19
Anda 1480'ishseharusnya 1460. Header IP dan header TCP masing-masing membutuhkan setidaknya 20 byte (kecuali jika digunakan header opsional) dan dengan demikian maks untuk Ethernet (non-Jumbo frame) 1500 - 20 -20 = 1460.
— Eugene Beresovsky
2
Saya telah melihat melalui wireshark bahwa server mengirim paket besar (lebih dari 1400 byte) dan klien menerimanya dibongkar karena beberapa paket maksimum 1400 byte. siapa yang bertanggung jawab atas pembongkaran paket? @Nektario ...?
— inbaly
2
@EugeneBeresovsky baik dengan header opsional itu + hingga 40 byte lebih, tapi itu variabel sehingga 1420 akan tampak batasnya. dengan saran 1400 Anda mendapatkan bantalan kecil. saya akan menggunakan 1408 karena ini dapat dibagi oleh 128
— Garet Claborn
22

Pada tingkat aplikasi, aplikasi menggunakan TCP sebagai protokol berorientasi aliran. TCP pada gilirannya memiliki segmen dan abstrak rincian bekerja dengan paket IP yang tidak dapat diandalkan.

Penawaran TCP dengan segmen bukan paket. Setiap segmen TCP memiliki nomor urut yang terkandung di dalam header TCP. Data aktual yang dikirim dalam segmen TCP adalah variabel.

Ada nilai getsockopt yang didukung pada beberapa OS yang Anda dapat menggunakan disebut TCP_MAXSEG yang mengambil ukuran segmen TCP maksimum (MSS). Ini tidak didukung pada semua OS.

Saya tidak yakin persis apa yang Anda coba lakukan tetapi jika Anda ingin mengurangi ukuran buffer yang digunakan Anda juga bisa melihat ke dalam: SO_SNDBUF dan SO_RCVBUF.

— Brian R. Bondy
sumber
Saya ingin tahu apakah Anda dapat menggunakan TCP sebagai antrian pesan jika Anda dapat memasukkan semua pesan Anda di dalam paket TCP yang besar?
— CMCDragonkai
4

Tidak ada paket di TCP API.

Sudah ada paket dalam protokol yang mendasarinya, seperti ketika TCP dilakukan melalui IP, yang Anda tidak tertarik, karena mereka tidak ada hubungannya dengan pengguna kecuali untuk optimasi kinerja yang sangat halus yang Anda mungkin tidak tertarik (sesuai dengan formulasi pertanyaan).

Jika Anda bertanya berapa jumlah maksimum byte yang Anda dapat send()dalam satu panggilan API, maka ini tergantung pada implementasi dan pengaturan. Anda biasanya akan memanggil kirim () untuk potongan hingga beberapa kilobyte, dan selalu siap untuk sistem untuk menolak untuk menerimanya secara total atau sebagian, dalam hal ini Anda harus mengelola pemisahan secara manual menjadi potongan-potongan kecil untuk memasukkan data Anda ke dalam TCP send () API.

— Pavel Radzivilovsky
sumber
8
TCP memiliki paket, serta header paket, yang bagiannya tumpang tindih header IP. Hanya karena Anda tidak seharusnya melihatnya bukan berarti itu tidak ada. TCP selalu dilakukan melalui IP. Anda tidak dapat melakukannya tanpa IP karena tumpang tindih header.
— Angin puyuh
23
@WhirlWind TCP memiliki segmen. IP memiliki paket.
— Marquis of Lorne
1
TCP memiliki segmen (atau menyebutnya paket, tidak apa-apa). TCP API tidak memiliki paket.
— Pavel Radzivilovsky
13
@NathanLong Kelemahannya adalah Anda menyebabkan kebingungan yang tidak perlu. TCP memiliki segmen, UDP memiliki datagram, IP memiliki paket, Ethernet memiliki bingkai, ...
— Marquis of Lorne
1
@Chexxor Jadi bahasa apa yang akan Anda gunakan untuk menggambarkan segmen TCP di dalam paket IP di dalam frame Ethernet? Sama sekali tidak perlu membingungkan masalah dengan menggunakan istilah yang sama untuk hal-hal yang berbeda, ketika penulis hal-hal ini telah mengalami banyak kesulitan untuk menggunakan istilah yang berbeda.
— Marquis of Lorne
3

Secara umum, ini akan tergantung pada antarmuka yang digunakan koneksi. Anda mungkin dapat menggunakan ioctl () untuk mendapatkan MTU, dan jika itu ethernet, Anda biasanya bisa mendapatkan ukuran paket maksimum dengan mengurangi ukuran header perangkat keras dari itu, yaitu 14 untuk ethernet tanpa VLAN.

Ini hanya terjadi jika MTU setidaknya sebesar itu di jaringan. TCP dapat menggunakan jalur penemuan MTU untuk mengurangi MTU efektif Anda.

Pertanyaannya adalah, mengapa kamu peduli?

— Angin puyuh
sumber
6
Itu hanya akan memberi Anda ukuran paket maksimum pada tautan pertama. Sejauh yang saya tahu, setiap node lain di sepanjang rute diperbolehkan untuk tidak suka paket besar dan mungkin terpecah di mana saja di sepanjang jalan.
— Matti Virkkunen
Yup, itu benar ... jadi pertanyaan Anda bagus - mengapa Anda menginginkan ini?
— Angin puyuh
Saya ingin mengirimkan video / gambar melalui koneksi LAN
— Alexa
1
Karena TCP berorientasi pada aliran, mengapa ini penting?
— Angin puyuh
3

Jika Anda menggunakan mesin Linux, "ifconfig eth0 mtu 9000 up" adalah perintah untuk mengatur MTU untuk sebuah antarmuka. Namun, saya harus mengatakan, MTU besar memiliki beberapa kelemahan jika transmisi jaringan tidak begitu stabil, dan mungkin menggunakan lebih banyak memori ruang kernel.

— DAG
sumber
3

Tampaknya sebagian besar situs web di internet menggunakan 1460 byte untuk nilai MTU. Kadang-kadang 1452 dan jika Anda menggunakan VPN itu akan turun lebih banyak untuk header IPSec.

Ukuran jendela standar bervariasi sedikit hingga maksimal 65535 byte. Saya menggunakan http://tcpcheck.com untuk melihat nilai IP sumber saya sendiri dan untuk memeriksa apa yang digunakan vendor Internet lainnya.

— David McCulloch
sumber
2

Salah satu solusinya adalah dengan mengatur opsi socket TCP_MAXSEG ( http://linux.die.net/man/7/tcp ) ke nilai yang "aman" dengan jaringan yang mendasarinya (mis. Set ke 1400 agar aman di ethernet) lalu gunakan buffer besar dalam panggilan sistem kirim. Dengan cara ini akan ada lebih sedikit panggilan sistem yang mahal. Kernel akan membagi data agar sesuai dengan MSS.

Dengan cara ini Anda dapat menghindari data terpotong dan aplikasi Anda tidak perlu khawatir tentang buffer kecil.

— hashtpaa
sumber
2

Ukuran paket untuk pengaturan TCP dalam protokol IP (Ip4). Untuk bidang ini (TL), 16 bit dialokasikan, sehingga ukuran maksimal paket adalah 65535 byte: Detail protokol IP

— Ziegfried
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.