network-transport.md (2945B)
1 +++ 2 title = 'Network transport' 3 +++ 4 5 ## Network transport 6 ### Congestion control 7 determine rate to send data, such that sender doesn't overrun network capability, and network is efficiently used 8 - switches have packet queue, packets dropped if not enough space in queue 9 - TCP sends data across network as fast as possible, but not faster 10 - end hosts control sending rate based on ACKs 11 - packet conservation principle: for connection in equilibrium, new packet shouldn't be put into network until an old packet leaves 12 13 self-clocking: new packets sent when packet leaves, at bottleneck rate. 14 15 quickly reaching equilibrium: TCP slow start 16 - upon receiving ACK, increase congestion window by 1 17 - timeout or 3 duplicate ACKs assumed to be packet drop 18 19 adapt to available space: additive increase multiplicative decrease (AIMD) 20 - congestion window increased by 1, but decreased by half of window size 21 22 BBR: congestion-based congestion control 23 - models network, estimates maxBW (bandwidth) and minRTT (round tirp time) on every ACK 24 - control sending rate based on model 25 - uses a state machine 26 27 ### Multi-path transport 28 Benefits: higher throughput, failover, seamless mobility 29 30 For unmodified apps, present same socket API and expectations, establish TCP connections in the normal way. Single flow by default, add sub-flows if possible. 31 32 MPTCP 33 - to add new sub-flow, use token hashed from key exchanged in handshake, HMAC for authentication. 34 - start sending packets with new IP/port pair, associate sub-flows with exiting connection 35 36 Middleboxes: network equipment that apply special operations on path of network packets (e.g. firewall, NAT) 37 - some check TCP sequence numbers 38 - solution: use per-flow sequence number 39 40 MPTCP congestion control: 41 - be fair to TCP at bottleneck links: take as much capacity as TCP, no matter how many paths it's using 42 - use efficient paths: each congestion should send all traffic on least-congested paths, but keep some traffic on alternative paths as probe 43 - perform as well as TCP 44 - don't oscillate 45 - so, maintains a congestion window for each sub-flow, using a formula that I hope we don't need to know 46 47 ### HTTP 48 HTTP/1 49 - 1 round trip to set up TCP connection 50 - 2 round trips to set up TLS 1.2 connection 51 - after setup, requests/responses flow over connection, one at a time 52 - head-of-line (HoL) blocking on HTTP connection 53 54 HTTP/1.1: avoid HoL blocking 55 - multiple TCP connections allow multiple objects to be fetched through concurrent HTTP requests/responses 56 57 HTTP/2: stream multiplexing 58 - multiple streams (each for an object) multiplexed on same TCP connection 59 - even multiple domains can share same TCP connection 60 - supports stream priority set by client 61 62 ### QUIC 63 new streaming protocol to make streaming faster 64 65 HTTP/3 over QUIC: 66 - 0 round trip to known server, or if crypto keys not new 67 - connections survive IP address change 68 - after setup, HTTP requests/responses flow over connection via QUIC streams