Penemuduga bertanya: Berapa banyak permintaan HTTP yang boleh dihantar oleh sambungan TCP?

Pernah ada soalan temu duga klasik: Apakah yang berlaku dalam proses daripada URL yang dimasukkan dalam penyemak imbas ke halaman yang dipaparkan?

Saya percaya bahawa kebanyakan pelajar yang telah menyediakan boleh menjawabnya, tetapi jika anda terus bertanya: Jika HTML yang diterima mengandungi berpuluh-puluh tag imej, dalam cara bagaimana, dalam susunan bagaimana, imej ini dicipta ? Berapa banyak sambungan telah dimuat turun dan apakah protokol yang digunakan?

Untuk memahami masalah ini, kita perlu menyelesaikan lima masalah berikut terlebih dahulu:

1 Selepas pelayar moden mewujudkan sambungan TCP dengan pelayan Will ia memutuskan sambungan selepas permintaan HTTP selesai? Dalam keadaan apa ia akan diputuskan?

2. Berapa banyak permintaan HTTP yang boleh sepadan dengan satu sambungan TCP?

3. Bolehkah permintaan HTTP dihantar bersama dalam sambungan TCP (contohnya, tiga permintaan dihantar bersama dan tiga respons diterima bersama)?

4. Mengapakah kadangkala memuat semula halaman tidak memerlukan sambungan SSL diwujudkan semula?

5. Adakah penyemak imbas mempunyai sebarang had pada bilangan sambungan TCP yang diwujudkan oleh Hos yang sama?

Soalan pertama

Adakah penyemak imbas moden akan memutuskan sambungan selepas permintaan HTTP selesai selepas mewujudkan sambungan TCP dengan pelayan ? Dalam keadaan apa ia akan diputuskan?

Dalam HTTP/1.0, pelayan akan memutuskan sambungan TCP selepas menghantar respons HTTP. Walau bagaimanapun, setiap permintaan akan mewujudkan semula dan memutuskan sambungan TCP, yang terlalu mahal. Jadi, walaupun ia tidak ditetapkan dalam piawaian, sesetengah pelayan menyokong sambungan: pengepala kekal hidup. Ini bermakna selepas melengkapkan permintaan HTTP ini, jangan putuskan sambungan TCP yang digunakan oleh permintaan HTTP. Kelebihan ini ialah sambungan boleh digunakan semula, dan tidak perlu mewujudkan semula sambungan TCP apabila menghantar permintaan HTTP nanti. Jika sambungan dikekalkan, overhed SSL juga boleh dielakkan dua lawatan saya ke www.github dalam tempoh yang singkat Statistik masa .com:

Lawatan pertama, terdapat sambungan permulaan dan overhed SSL

<.>

Sambungan permulaan dan overhed SSL Overhed hilang, menunjukkan bahawa sambungan TCP yang sama digunakan

Sambungan berterusan: Memandangkan terdapat begitu banyak faedah mengekalkan sambungan TCP, HTTP /1.1 menulis pengepala Sambungan ke dalam standard dan membolehkan sambungan berterusan secara lalai melainkan ditulis dalam permintaan Jika Sambungan: tutup ditentukan, sambungan TCP antara penyemak imbas dan pelayan akan dikekalkan untuk tempoh masa dan tidak akan diputuskan sambungan selepas permintaan telah selesai.

Jadi jawapan kepada soalan pertama ialah: secara lalai sambungan TCP tidak diputuskan, hanya mengisytiharkan Sambungan: tutup dalam pengepala permintaan akan menutup sambungan selepas permintaan selesai.

Soalan kedua

Berapa banyak permintaan HTTP yang boleh sepadan dengan sambungan TCP?

Selepas memahami soalan pertama, soalan ini sebenarnya sudah mempunyai jawapan Jika sambungan dikekalkan, sambungan TCP boleh menghantar berbilang permintaan HTTP.

Soalan ketiga

Bolehkah permintaan HTTP dihantar bersama dalam sambungan TCP (contohnya, tiga permintaan dihantar bersama dan tiga respons diterima bersama)?

Terdapat masalah dengan HTTP/1.1 Satu sambungan TCP hanya boleh mengendalikan satu permintaan pada masa yang sama, yang bermaksud: kitaran hayat dua permintaan tidak boleh bertindih mana-mana dua permintaan HTTP adalah Tidak boleh bertindih dalam sambungan TCP yang sama.

Walaupun spesifikasi HTTP/1.1 menentukan Pipelining untuk cuba menyelesaikan masalah ini, ciri ini dimatikan secara lalai dalam penyemak imbas.

Mari kita lihat dahulu apa itu Pipelining yang ditetapkan oleh RFC 2616:

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received. 一个支持持久连接的客户端可以在一个连接中发送多个请求（不需要等待任意请求的响应）。收到请求的服务器必须按照请求收到的顺序发送响应。

Mengenai mengapa standard ditetapkan dengan cara ini, kita boleh membuat spekulasi secara kasar atas satu sebab: kerana HTTP/. 1.1 ialah protokol teks , dan kandungan yang dikembalikan tidak dapat membezakan permintaan mana yang sepadan, jadi pesanan mesti dikekalkan secara konsisten. Sebagai contoh, jika anda menghantar dua permintaan kepada pelayan, GET/query?q=A dan GET/query?q=B, dan pelayan mengembalikan dua hasil, penyemak imbas tidak mempunyai cara untuk menentukan permintaan yang sepadan dengan respons berdasarkan hasil tindak balas.

Pelipisan Paip Idea ini kelihatan bagus, tetapi terdapat banyak masalah dalam amalan:

• Sesetengah pelayan proksi tidak dapat mengendalikan Paip HTTP dengan betul.

• Pelaksanaan saluran paip yang betul adalah rumit.

• Sekatan Ketua Talian: Selepas mewujudkan sambungan TCP, anggap bahawa klien menghantar beberapa permintaan kepada pelayan secara berterusan semasa sambungan ini. Mengikut piawaian, pelayan harus mengembalikan hasil dalam urutan permintaan diterima Dengan mengandaikan bahawa pelayan menghabiskan banyak masa memproses permintaan pertama, maka semua permintaan berikutnya perlu menunggu permintaan pertama selesai sebelum menjawab. .

Jadi penyemak imbas moden tidak mendayakan HTTP Pipelining secara lalai.

Walau bagaimanapun, HTTP2 menyediakan ciri Multiplexing, yang boleh melengkapkan berbilang permintaan HTTP secara serentak dalam sambungan TCP. Bagaimana tepatnya pemultipleksan dilaksanakan adalah soalan lain. Kita boleh melihat kesan penggunaan HTTP2.

Hijau ialah masa menunggu dari memulakan permintaan hingga mengembalikan permintaan, dan biru ialah masa muat turun respons Anda dapat melihat bahawa semuanya telah selesai selari dalam Sambungan yang sama

Jadi soalan ini juga mempunyai jawapan: dalam HTTP/1.1, terdapat teknologi Pipelining yang boleh melengkapkan penghantaran berbilang permintaan pada masa yang sama, tetapi memandangkan penyemak imbas ditutup secara lalai, ia boleh dianggap tidak boleh dilaksanakan. Disebabkan oleh ciri Multiplexing dalam HTTP2, berbilang permintaan HTTP boleh diproses secara selari pada sambungan TCP yang sama.

Jadi dalam era HTTP/1.1, bagaimanakah penyemak imbas meningkatkan kecekapan pemuatan halaman? Terdapat dua perkara utama:

• Kekalkan sambungan TCP yang telah diwujudkan dengan pelayan dan proses berbilang permintaan secara berurutan pada sambungan yang sama.

• Mewujudkan berbilang sambungan TCP dengan pelayan.

Soalan keempat

Mengapa kadangkala memuat semula halaman tidak memerlukan sambungan SSL diwujudkan semula?

Jawapan sudah tersedia dalam perbincangan soalan pertama sambungan TCP kadangkala diselenggara oleh penyemak imbas dan pelayan untuk satu tempoh masa. TCP tidak perlu diwujudkan semula, dan SSL secara semula jadi akan menggunakan yang sebelumnya.

Soalan kelima

Adakah terdapat sebarang had pada bilangan sambungan TCP yang penyemak imbas boleh wujudkan kepada Hos yang sama?

Andaikan kita masih dalam era HTTP/1.1, dan tiada pemultipleksan pada masa itu Apakah yang perlu dilakukan oleh penyemak imbas apabila ia mendapat halaman web dengan berpuluh-puluh imej? Sudah pasti tidak mungkin untuk hanya membuka sambungan TCP untuk muat turun berurutan, jika tidak, pengguna pasti perlu menunggu Walau bagaimanapun, jika sambungan TCP dibuka untuk setiap gambar untuk menghantar permintaan HTTP, komputer atau pelayan mungkin tidak dapat menanggungnya Jika terdapat 1,000 gambar, ia tidak boleh dibuka 1000 sambungan TCP, walaupun komputer anda bersetuju dengan NAT, ia mungkin tidak bersetuju.

Jadi jawapannya: ya. Chrome membenarkan sehingga enam sambungan TCP ke Hos yang sama. Terdapat beberapa perbezaan antara pelayar yang berbeza.

developers.google.com/web/tools/ch...

Jadi kembali kepada soalan asal, jika HTML yang diterima mengandungi berpuluh-puluh imej Tag, dalam cara bagaimana, dalam susunan apa, berapa banyak sambungan telah diwujudkan, dan apakah protokol yang digunakan untuk memuat turun gambar-gambar ini?

Jika imej adalah semua sambungan HTTPS dan di bawah nama domain yang sama, penyemak imbas akan berbincang dengan pelayan selepas jabat tangan SSL sama ada HTTP2 boleh digunakan, fungsi Multiplexing akan digunakan untuk menjalankan pemultipleksan sambungan ini. Walau bagaimanapun, tidak semestinya semua sumber yang disenaraikan pada nama domain ini akan diperoleh menggunakan sambungan TCP, tetapi pastinya pemultipleksan mungkin akan digunakan.

Bagaimana jika anda mendapati anda tidak boleh menggunakan HTTP2? Atau HTTPS tidak boleh digunakan (sebenarnya, HTTP2 dilaksanakan pada HTTPS, jadi hanya HTTP/1.1 boleh digunakan). Penyemak imbas akan mewujudkan berbilang sambungan TCP pada HOST Had maksimum pada bilangan sambungan bergantung pada tetapan penyemak imbas Sambungan ini akan digunakan oleh penyemak imbas untuk menghantar permintaan baharu jika semua sambungan menghantar permintaan Woolen cloth? Kemudian permintaan lain perlu menunggu.                                                                                                 

Atas ialah kandungan terperinci Penemuduga bertanya: Berapa banyak permintaan HTTP yang boleh dihantar oleh sambungan TCP?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!