一石二鳥 0125名刺は切らしておりまして2022/06/08(水) 22:38:14.37ID:2rozZg0z QUIC aims to be nearly equivalent to a TCP connection but with much-reduced latency. It does this primarily through two changes that rely on the understanding of the behaviour of HTTP traffic.[22]
The first change is to greatly reduce overhead during connection setup. As most HTTP connections will demand TLS, QUIC makes the exchange of setup keys and supported protocols part of the initial handshake process. When a client opens a connection, the response packet includes the data needed for future packets to use encryption. This eliminates the need to set up the TCP connection and then negotiate the security protocol via additional packets. Other protocols can be serviced in the same way, combining together multiple steps into a single request-response. This data can then be used both for following requests in the initial setup, as well as future requests that would otherwise be negotiated as separate connections.[22] 0126名刺は切らしておりまして2022/06/08(水) 22:38:48.38ID:2rozZg0z The second change is to use UDP rather than TCP as its basis, which does not include loss recovery. Instead, each QUIC stream is separately flow controlled and lost data is retransmitted at the level of QUIC, not UDP. This means that if an error occurs in one stream, like the favicon example above, the protocol stack can continue servicing other streams independently. This can be very useful in improving performance on error-prone links, as in most cases considerable additional data may be received before TCP notices a packet is missing or broken, and all of this data is blocked or even flushed while the error is corrected. In QUIC, this data is free to be processed while the single multiplexed stream is repaired.[23] 0127名刺は切らしておりまして2022/06/08(水) 22:41:57.54ID:s2lW6iew コマンドをアスキーで送るとか正気の沙汰じゃないね 0128名刺は切らしておりまして2022/06/08(水) 22:56:08.60ID:idArNWf7 UDPで無駄な再送減らせるのは良いとして、途中の経路での支援は受けられなくなるよね 少なくとも今のところは 0129名刺は切らしておりまして2022/06/08(水) 23:00:16.61ID:P7fZeVou>>38 NATが心配 0130名刺は切らしておりまして2022/06/08(水) 23:08:59.58ID:6v66TjDh (´・ω・`)何この誰もわかんないニュース 0131名刺は切らしておりまして2022/06/08(水) 23:18:48.37ID:PGSJBWBr>>107 機能追加とかではなく、高速化というメリットだから誰もが恩恵受ける万能的なものだよ 対応しないのはユーザー視点より自身の利益を見てるだけ 0132名刺は切らしておりまして2022/06/08(水) 23:36:25.56ID:X0Dj6QUp>>129 大量のコネクション張るような使い方だとNATテーブル溢れちゃうかもね 安いルータだとNATテーブルの上限小さかったりするし ただ、一つのコネクションで複数ストリームを流せるのでアプリケーション の実装次第でそこまで問題にならないのでは 0133名刺は切らしておりまして2022/06/08(水) 23:41:05.28ID:Kjm/CGBS HVDCも早よ 0134名刺は切らしておりまして2022/06/09(木) 01:02:37.58ID:a7vc0g0U 田代砲の威力減弱するってこと? 0135名刺は切らしておりまして2022/06/09(木) 01:13:34.59ID:viC79xh/>>7 うるせえ、全部英語でええわ 0136名刺は切らしておりまして2022/06/09(木) 01:14:13.00ID:viC79xh/>>130 通信遅延が少なくなると思ってくれればええよ 0137名刺は切らしておりまして2022/06/09(木) 03:54:44.94ID:LoLKYy1h そらUDPで確実に通信できるならUDPのほうがいいよね 0138名刺は切らしておりまして2022/06/09(木) 05:25:53.81ID:CU8CAwdP>>7 全部漢字に訳す中国人か? 0139名刺は切らしておりまして2022/06/09(木) 06:42:36.13ID:SvOVy2Et>>117 あは それ横書きな あはは 0140名刺は切らしておりまして2022/06/09(木) 07:39:18.96ID:AcwI1A/n UDPで再送出来るようになるんか。 HTTP以外でも使えれば変革が起きそう。 ま、ユーザは何もわからんけどw 0141名刺は切らしておりまして2022/06/09(木) 07:42:23.39ID:Z9aK7ola 最終的にはリソースクラッシュ起因のトータルギッダムが起きてマスターコンベクターが右往左往するみたいなイメージだな 0142名刺は切らしておりまして2022/06/09(木) 08:00:20.51ID:+Bl5Z0iA UDPって懐かしいわ、PKG間の通信で使ってた あの頃は楽しかったわ 0143名刺は切らしておりまして2022/06/09(木) 08:07:18.56ID:OXL6L1SJ>>68 コードの部分は英語or日本語? 0144名刺は切らしておりまして2022/06/09(木) 08:22:19.47ID:q92ie1Gn QUIC仕様がグダグダだったから前途多難で短命で終わるだろうと見ている 最先端のリアルタイム通信処理開発はすでにQUICを捨てて独自開発を進めている その中で成功したものが次の規格の土台なる 0145名刺は切らしておりまして2022/06/09(木) 08:31:34.09ID:Fz7KBqfS 脱TCP?は大ウソ だしWebだけだし