Polling - Mimic real-time event delivery via HTTP Client LEGY fetchOps {rev: 1, count: 100} Talk fetchOps {rev: 1, count: 100} No Content fetchOps {rev: 1, count: 100} publish Response OP created fetchOps {rev: 101, count: 100} Response OP is the unit of event in LINE
Header Cache - Same HTTP headers are transferred repeatedly - LEGY holds caches for such headers - HTTP request gets smaller - Headers can be compressed using zlib - High server memory usage - Couldn’t support compression for some connections SPDY LINE
Header Cache - Same HTTP headers are transferred repeatedly - LEGY holds caches for such headers - HTTP request gets smaller - Headers can be compressed using zlib - High server memory usage - Couldn’t support compression for some connections SPDY LINE Client LEGY header1: value1 header2: value2 Server header1: value1 header2: value2 cache key header3: value3 header1: value1 header2: value2 Header3: value3 cache key
SPDY - Enables multiple responses for a single request - The pushes are associated with a request - The pushes MUST be made before closing the request - Use case is fetching resources to render web pages
Custom SPDY Push SPDY LINE - LINE’s some features and services follow subscribe/push pattern - The pushes are not associated with a request - Original request is closed before the pushes - Enables multiple responses for a single request - The pushes are associated with a request - The pushes MUST be made before closing the request - Use case is fetching resources to render web pages
Custom SPDY Push SPDY LINE - LINE’s some features and services follow subscribe/push pattern - The pushes are not associated with a request - Original request is closed before the pushes Client LEGY Subscribe Service Subscribe Push OK OK Push (asso. with stream 0) Push Push (asso. with stream 0) - Enables multiple responses for a single request - The pushes are associated with a request - The pushes MUST be made before closing the request - Use case is fetching resources to render web pages
Custom SPDY Push SPDY LINE - LINE’s some features and services follow subscribe/push pattern - The pushes are not associated with a request - Original request is closed before the pushes Note that fetchOps still works through long polling - Enables multiple responses for a single request - The pushes are associated with a request - The pushes MUST be made before closing the request - Use case is fetching resources to render web pages Client LEGY Subscribe Service Subscribe Push OK OK Push (asso. with stream 0) Push Push (asso. with stream 0)
TLS SPDY - Use TLS for connection-wise encryption - Not mandatory but recommended - Overhead for slow network and clients - Resulted in bad user experience in 3G
2012 LEGY Encryption - Lightweight in-house encryption method - Encrypt message body and sensitive headers not whole connection - Effective for clients with 3G environment SPDY LINE - Use TLS for connection-wise encryption - Not mandatory but recommended - Overhead for slow network and clients - Resulted in bad user experience in 3G
2012 LEGY Encryption SPDY LINE - Use TLS for connection-wise encryption - Not mandatory but recommended - Overhead for slow network and clients - Resulted in bad user experience in 3G Original LEGY Encryption Applied Headers Body Header part Body part Sensitive Headers + Body LE Headers Non-sensitive Headers Header part Body part - Lightweight in-house encryption method - Encrypt message body and sensitive headers not whole connection - Effective for clients with 3G environment
our SPDY protocol - It makes code management harder Outdated Protocol Safer but Heavy TLS - TLS is safer than LEGY Encryption and gets evolved - The handshake is still heavy - Our SPDY protocol itself is not conformant to the specification - It’s confusing ⇨ Errors, bugs Standard Inconformity SPDY Header Cache Custom Push LEGY Encryption
to stable LEGY PoPs. LEGY PoP Status - Each client has different application policy. Different Client Types - Each country has different network characteristics. Different Countries - As client is updated, features are added and removed. Different Client Versions
Conn-info Repository export import LEGY conn-info default conn-info Periodically fetch conn-info w/ local cache Use HTTP/2 with TLS Use SPDY with LEGY Encryption
Dogfooding Domain Client SPDY for normal users Conn-info HTTP/2 + SPDY Normal Domain Client HTTP2 for JP only Conn-info HTTP/2 + SPDY Normal Domain Client Fully respect conn-info Dogfooding JP LINE All Regions Beta/RC production
Dogfooding Domain Client SPDY for normal users Conn-info HTTP/2 + SPDY Normal Domain Client HTTP2 for JP only Conn-info HTTP/2 + SPDY Normal Domain Client Fully respect conn-info Dogfooding JP LINE All Regions Beta/RC 85% of connections use HTTP/2 production
the server are sent on that explicit request's stream. Client LEGY Subscribe Service Subscribe OK Push PUSH_PROMISE (B) OK PUSH_PROMISE (C) Push Stream A Stream B ❌
CLIENT LEGY Lib + OS Client terminated the subscription. Connection Request Response Connection Subscription succeeded. Server will let me know when data is available.
text/plain Transfer-Encoding: chunked 7\r\n Mozilla\r\n 9\r\n Developer\r\n 7\r\n Network\r\n 0\r\n \r\n * Example from https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding#examples Client Server Request Headers (chunked transfer) 7\r\nMozilla\r\n Data Created 9\r\nDeveloper\r\n Data Created 7\r\nNetwork\r\n Data Ceated 0\r\n\r\n Nothing More
E = 0 to E = 0 DEV E = 0 DAY E = 1 2021 Sender Receiver Welcome to DEVDAY 2021 7\r\n Welcome\r\n 4\r\n 2021\r\n 2\r\n to\r\n 3\r\n DEV\r\n 3\r\n DAY\r\n 0\r\n \r\n
HEADERS (status:200) DATA (sign-on) Stream 1 Service1 Service2 Subscribe Subscribe DATA (sign-on results) OK OK PUSH DATA (push) DATA (push ack) Push Session Established
HEADERS (status:200) DATA (fetchOps sign-on) Stream 1 Talk fetchOps DATA (sign-on result) Empty publish fetchOps Response OP created DATA (fetchOps sign-on) Push Session Established
Server ClientHello TCP Handshake ServerHello + Finished Finished + Application Data ClientHello + Application Data ServerHello + Finished + ApplicationData Finished + Application Data TLSv1.3 TLSv1.3 0-RTT Additional 1 RTT regardless of Session resumption 20% of connections are using still TLSv1.2
Application Data TLSv1.2 First Connection TCP Handshake Client Server TCP Handshake ClientHello ServerHello + Finished Finished + Application Data TLSv1.2 Second Connection Don’t renegotiate
Application Data TLSv1.2 First Connection TCP Handshake Client Server TCP Handshake ClientHello ServerHello + Finished Finished + Application Data TLSv1.2 Second Connection Session ID & Session Ticket
line_devday2021
itkq
dayjournal
maimyyym
kaz1437
nina01
kaz29
cybozuinsideout
visional_engineering_and_design
ryysud
coconala_engineer
8maki
colopl
mongodb
eitanlees
danielanewman
pedronauck
myddelton
bluesmoon
geoffreycrofte
deanohume
keavy
philhawksworth
reverentgeek
mza
