成人国产在线小视频_日韩寡妇人妻调教在线播放_色成人www永久在线观看_2018国产精品久久_亚洲欧美高清在线30p_亚洲少妇综合一区_黄色在线播放国产_亚洲另类技巧小说校园_国产主播xx日韩_a级毛片在线免费

資訊專欄INFORMATION COLUMN

TCP Connection Reuse on HTTP/1.1 and 2.0

k00baa / 2933人閱讀

I saw the introduction of http/2.0 in developers.google.com. However, I feel confused about the request and response multiplexing. So I decided to make a demo or an example for better understanding.

TCP Connection Reuse

When I saw the TCP connection reuse, I had a lot of questions in my head. For instances,

how do I know if the TCP was reused?

What would the network be if the TCP wasn"t reused?

It seems that HTTP 1.1 also supports TCP connection reuse. So, what"s the difference?

....

After searching, I found that there is a Connection ID column in the chrome dev tool Network panel. For example, here is the network image of baidu.com :

According to this question

The new Connection ID Network Panel column in Canary can help indicate to you that a TCP connection was reused instead of handshaking and establishing a new one.

Combined with the above image, we can say that in the network panel of baidu.com

Requests to ss1.bdstatic.com are based on H2 (HTTP2.0.) and share the same TCP connection because there is only one connection ID.

Requests to www.baidu.com are based on http/1.1 and 6 requests share two TCP connections because there are two connection IDs.

It seems http/1.1 also support TCP connection Reuse. So, how can I prove the advantages of H2 or what"s the difference between the connection reuse of http/1.1 and 2.0? That confused me in the past.

Prove The Advantages of H2

I pick two requests from the network record and then fetch it at the console. The code of requests to http/1.1 is:

Array(13)
  .fill()
  .forEach(() => {
    fetch("https://www.baidu.com/favicon.ico", {
      credentials: "omit",
      referrer: "https://www.baidu.com/",
      referrerPolicy: "unsafe-url",
      body: null,
      method: "GET",
      mode: "cors"
    })
  })

And the code of requests to http/2.0 is:

Array(13)
  .fill()
  .forEach(() => {
    fetch(
      "https://ss3.baidu.com/6ONWsjip0QIZ8tyhnq/ps_default.gif?_t=1556369856347",
      {
        credentials: "omit",
        referrer: "https://www.baidu.com/",
        referrerPolicy: "unsafe-url",
        body: null,
        method: "GET",
        mode: "cors"
      }
    )
  })

Here are the results:

Take a closer look at the pictures, we can find that

On http/1.1 connections, chrome would open up to 6 TCP connections per host and reuse the connections. While on http/2.0 connections, chrome would open only one TCP connection per host on http/2.0 connections.

Also, on http/1.1 connections chrome would send the requests one by one when the requests are using the same TCP connection. Just as the developers.google.com said:

On HTTP 1.0/1.1 connections, Chrome enforces a maximum of six TCP connections per host. If you are requesting twelve items at once, the first six will begin and the last half will be queued. Once one of the original half is finished, the first item in the queue will begin its request process.

This would bring more delay when sending more requests.

While on http/2.0 connections, chrome would send all the requests to the same origin simultaneously without delay.

Differences of TCP Connection Reuse between HTTP/1.1 and 2.0

On http/1.1 connections, chrome would reuse TCP connection by default and you can find

Connection: keep-alive

in the response headers. But according to docs in mdn

This connection will not stay open forever: idle connections are closed after some time (a server may use the Keep-Alive header to specify a minimum time the connection should be kept open).

And for http/2.0, according to developers.google.com

all http/2.0 connections are persistent, and only one connection per origin is required, which offers numerous performance benefits.

Source

Reference

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/103952.html

相關(guān)文章

  • 自己寫一個 wsgi 服務(wù)器運行 Django 、Tornado 等框架應(yīng)用

    摘要：要使用協(xié)議我們不可能自己實現(xiàn)一個，現(xiàn)在比較流行的解決方案就是使用套接字編程，已經(jīng)幫我們實現(xiàn)了協(xié)議的細節(jié)，我們可以直接拿來使用不用關(guān)心細節(jié)。 前幾天寫了 淺談cgi、wsgi、uwsgi 與 uWSGI 等一些 python web 開發(fā)中遇到的一些名詞的理解，今天博主就根據(jù) wsgi 標準實現(xiàn)一個 web server，并嘗試用它來跑 Django、tornado 框架的 app。 編...

    lunaticf 評論0 收藏0

  • 「旁門右道」CURL持久連接技巧

    摘要：支持多路復(fù)用支持對和已建立連接的復(fù)用，如果舊連接已失效則主動關(guān)閉舊連接，如果連接有效則嘗試使用已有連接傳輸數(shù)據(jù)。 背景 對于同一服務(wù)可能存在多次調(diào)用的情況，然而每次調(diào)用都需要建立一次tcp連接導(dǎo)致大量重復(fù)工作的同時還增加了連接超時或連接錯誤的概率，為了減少tcp連接次數(shù)最大限度的提高連接利用率，需要能夠重復(fù)利用每個tcp連接。 原理 HTTP1.1與HTTP2.0支持對于一次TCP連...

    dongfangyiyu 評論0 收藏0

  • 自從我這樣擼代碼以后，公司網(wǎng)頁的瀏覽量提高了107%！

    摘要：假如我們底層的連接得到重用，這時候的情況會是這樣子很明顯，在獲取的請求中，減少了一次握手往返。在使用持久連接后，避免了一次握手往返總延遲減少為。其代價往往是不能充分利用網(wǎng)絡(luò)連接，造成服務(wù)器緩沖開銷，有可能導(dǎo)致客戶端更大的延遲。 歡迎大家前往騰訊云+社區(qū)，獲取更多騰訊海量技術(shù)實踐干貨哦~ 本文由騰訊IVWEB團隊 發(fā)表于云+社區(qū)專欄作者：yangchunwen HTTP協(xié)議是前端性能乃...

    sutaking 評論0 收藏0

  • 自從我這樣擼代碼以后，公司網(wǎng)頁的瀏覽量提高了107%！

    摘要：假如我們底層的連接得到重用，這時候的情況會是這樣子很明顯，在獲取的請求中，減少了一次握手往返。在使用持久連接后，避免了一次握手往返總延遲減少為。其代價往往是不能充分利用網(wǎng)絡(luò)連接，造成服務(wù)器緩沖開銷，有可能導(dǎo)致客戶端更大的延遲。歡迎大家前往騰訊云+社區(qū)，獲取更多騰訊海量技術(shù)實踐干貨哦~ 本文由騰訊IVWEB團隊發(fā)表于云+社區(qū)專欄 作者：yangchunwen HTTP協(xié)議是前端性能乃至...

    lixiang 評論0 收藏0

  • HTTP1.1 Keep-Alive到底算不算長連接？

    摘要：在基礎(chǔ)架構(gòu)部沉浸了半年，有一些認知刷新想和童靴們交代一下，不一定全面，僅代表此時的認知，也歡迎筒靴們提出看法。本文聊一聊口嗨用語長連接短連接，文章會按照下面的思維導(dǎo)圖來講述在基礎(chǔ)架構(gòu)部沉浸了半年，有一些認知刷新想和童靴們交代一下， 不一定全面，僅代表此時的認知， 也歡迎筒靴們提出看法。本文聊一聊口嗨用語：長連接、短連接， 文章會按照下面的思維導(dǎo)圖來講述：

    shleyZ 評論0 收藏0

發(fā)表評論

0條評論

k00baa

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<