High Performance Browser Network review

1. High Performance Browser
Network - Wired network
Jordan@Synergies
1

2. Bandwidth and Latency
2

3. Bandwidth 與 Latency
3

4. 造成 Latency 的因素
● Processing delay : 網路節點處理封包的時間 (ex:接下來送給誰)
● 佇列 (Queuing delay): 封包在網路節點的 queue 中等待被從 network interface 發送
到下一節點的時間
● 傳送 (Transmission delay): 由網路設備的頻寬決定
● 傳播 (Propagation delay): 距離遠近
ref:https://www.jannet.hk/zh-Hant/post/end-to-end-delay/ 4

5. 利用 traceroute 來量測 Latency
5

6. traceroute and ICMP
● ICMP 封包包含在 IP 中
6

7. traceroute 原理
● 發送 ICMP 封包
● 要求收到的 router 給回應
● TTL 由 1 開始遞增，直到收到 echo reply
7
https://www.wandouip.com/t5i220875/

8. 提高 Network performance
● 降低 Round Trip Times (RTT)
● 將資料搬移至 client 附近
● Pre-fetch
● Cache (CDN)
8

9. TCP
9

10. TCP Properties
10
● Provides an effective abstraction of a reliable network running over
an unreliable channel
○ in-order delivery
○ data integrity
○ Retransmission of lost data
○ congestion control and avoidance

11. Three-Way Handshake
11

12. Three-Way Handshake
● 每個 TCP connection 都需要
● 造成 delay 過高 expensive
● 解法:
○ 重複使用 TCP connection
○ TCP fast open
12

13. TCP Fast Open (TFO)
● an extension of TCP that helps
reduce network latency
● enabling data to be exchanged
during the sender’s initial TCP SYN.
Ref: https://www.keycdn.com/support/tcp-fast-open
13

14. TCP Fast Open (TFO)
1. The sender sends a SYN packet along with a cookie
request
2. The receiver generates the requested cookie and
sends a SYN-ACK along with the cookie back to the
sender
3. The client caches the cookie for the particular
server’s IP
Ref: https://www.keycdn.com/support/tcp-fast-open
1. The sender sends a packet containing a SYN, TFO
cookie, and data
2. The receiver validates the TFO cookie and sends
back a SYN-ACK and continues to send more data
packets to the client
3. The client sends an ACK back to the receiver
14

15. Enable TFO on Linux
echo 3 > /proc/sys/net/ipv4/tcp_fastopen
# 在/etc/sysctl.conf中添加
net.ipv4.tcp_fastopen = 3
https://www.wikiwand.com/zh-tw/TCP%E5%BF%AB%E9
%80%9F%E6%89%93%E5%BC%80 15

16. Network Congestion
16
● Network congestion in data networking and queueing theory is the reduced
quality of service that occurs when a network node or link is carrying more data
than it can handle. Typical effects include queueing delay, packet loss or the
blocking of new connections. A consequence of congestion is that an incremental
increase in offered load leads either only to a small increase or even a decrease in
network throughput.[1]
● Network protocols that use aggressive retransmissions to compensate for packet
loss due to congestion can increase congestion, even after the initial load has
been reduced to a level that would not normally have induced network
congestion. Such networks exhibit two stable states under the same level of load.
The stable state with low throughput is known as congestive collapse.

17. Congestion Avoidance and Control
17
● Flow Control (傳送端與接收端的事)
● Congestion Control (整體網路的事)
○ Slow Start
○ Congestion Avoidance

18. Flow Control
18
● 傳送數據的時候，如果對方收不下那
麼多封包，就會產生 packet drop 的
現象
● TCP 設計了 Receive Window
(RWND)，接收方要回報自己的
RWND 有多大，傳送方知道了這個
數值後，才不會多送封包過去造成浪
費。

19. 查詢與設定 RWND
19
sysctl -a | grep mem
net.ipv4.tcp_rmem = <MIN> <DEFAULT> <MAX>

20. Why Congestion control?
20
避免 高速傳送端 癱瘓 整體網路。
防止過多的數據注入到網路中，這樣可以使網路中的路由器
或鏈路不致過載。擁塞控制所要做的都有一個前提：網絡能
夠承受現有的網絡負荷。擁塞控制是一個全局性的過程，涉
及到所有的主機、路由器，以及與降低網絡傳輸性能有關的
所有因素
https://notfalse.net/28/tcp-congestion-control#-Congestio
n-Control-Algorithms

21. Slow Start (緩步啟動)
21
● TCP 開始傳輸到未知條件的網絡時，需緩慢地探測網絡
，以確定可用容量，避免因不適當的大量數據並發而使網
絡壅塞。
● 有點像是騎車，在道路狀況未明時慢慢騎，發現路況不錯
後就飆起來。
● 引入Congestion Window (CWND)，透過更改 CWND 的
大小去找到最佳值。

22. Slow Start (緩步啟動)
22
● 網路上每個 sender 各有一個自己的
CWND, 用來決定可以發送多少 packet
到 network 而不造成阻塞
● Sender 每收到一個 ACK 就 double
CWND
● 直到
○ CWND > receiver’s RWND
○ CWND > 系統設定的 CWND
threshold
○ Packet loss
● 啟動 Congestion Avoidance Algo.

23. UDP
23

24. UDP Properties
24
● UDP 屬於不可靠的協定，因此並無法保證封包一定可以到達目的地
○ No guarantee of message delivery
○ No guarantee of order of delivery
○ No connection state tracking
○ No congestion control

25. Transport Layer Security
(TLS)
25

26. SSL and TLS
26
● SSL (Secure Sockets Layer) 是 TLS 的前身，由 Netscape 開發來
確保電子商務交易安全。
● 確保網際網路連線安全以及防止在兩個系統之間發送的所有敏感
資料被罪犯讀取及修改任何傳輸的資訊
● 由於 SSL 屬於 Netscape 的智財，經過 Internet Engineering
Task Force (IETF) 標準化後為 TLS，最新版為 TLS 1.3
● TLS 是基於 TCP，在 UDP 上可使用對應的 DTLS
● TLS 提供 3 個面向的安全性
○ Encryption
○ Authentication
○ Integrity

27. HyperText Transfer Protocol Secure
(HTTPS)
27
● Unencrypted communication—via HTTP and other
protocols—creates a large number of privacy, security, and
integrity vulnerabilities.
● With HTTPS
○ protects the integrity of the website
○ protects the privacy and security of the user
○ enables powerful features on the web
■ 取得 user 地理資訊
■ 拍照、錄影
■ 使用者喜好
■ 有可靠的安全性，使用者才敢使用

28. TLS Handshake
28
● 在 client、server 能開始安全地傳送資料前
，要先建立安全通道
● 確認彼此的
○ TLS protocol 版本
○ Ciphersuite
○ verify certificates (optional)

29. TLS Handshake
29
● ClientHello: 提供自己跑的 TLS 版本、支援
的 ciphersuites 和其他 TLS 參數。
● ServerHello: 根據 client 提供的資訊選擇
TLS 版本、ciphersuites和 certification 回傳
給 client。也可要求 client 回傳他自己的
certification 和一些 TLS 參數。

30. TLS Handshake
30
● ClientKeyExchange: 假設雙方認證 certification
沒問題且達成包含 TLS version, ciphersuites 的共
識，則 client 會利用 RSA/Diffle-Hellman 等 key
exchange protocal 初始 key exchange
parameter，並把這些資訊傳給 server，這些資訊
用來讓 client server 共同決定一把金鑰，用來加密
session
● ChagneCipherSpec: server 收到 client 傳來的
key exchange parameter，確保其沒有被動過手腳
後，回傳 Encrypted Finished
● Finished: Client 利用剛剛協調好的金鑰解密資訊
，並確保沒被動過手腳。則加密通道被建立，之後
的通訊都是安全的。

31. 對稱式與非對稱式金鑰
31
● Diffle-Hellman 屬於 非對稱金鑰 (ASymmetric
Key),若採用的話會產生 4 把 key
○ Client’s Public
○ Client’s Private
○ Server’s Public
○ Server’s Private

32. TLS Session Resumption
32
● TLS Handshake 費時，是否可以儲存並沿用之前協
調好的 key ？
● TLS 2.0 提出 Session Identifiers，並在 ServerHello
時傳回給 Client
● 之後 Client 再發起新的 Session 時，可以在
ClientHello 時將 ID 發給 server，就可延用之前的
key
● 省了一個 RTT

33. Session Identifier 的缺點與改進
33
● Server 對每個 connection 都要 maintain 一個
Session ID，記憶體可能炸掉
● 在 Load balance 情況下，多個 host 間的 session
Identifier 同步問題
● Session ticket 被提出解決此問題
● 將 session data 用只有 server 知道的 key 加密後存
在 client，client 如要沿用之前的協調好的 key 則
將此加密的 session data 傳給 server，server 解密
後可以快速完成 TLS handshake.

34. Reduce TLS Computation Cost
34
● 對稱式加密和非對稱式加密都會對 client / server
雙方帶來額外的 computation cost
● 早期的電腦甚至會有獨立的晶片組負責加解密
(SSL offloading)
● 現今的 CPU 算力已經足夠，根據 google 提出的統
計 TLS 只比沒有 TLS 多出 (per connection)
○ 1 % of CPU loading
○ 10 KB Memory
○ 2 % Network overhead