애니메이션

일반 함수의 this 는 호출 방식에 따라 매번 다르게 바인딩되고, 화살표 함수의 this 는 정의된 위치의 Lexical Environment 에서 가져온다.

ThreadLocal.set 값이 호출 스레드의 ThreadLocalMap 에만 저장되어 다른 스레드에선 보이지 않음을 보여 줌.

Vector 의 모든 public 메서드가 synchronized 라 두 스레드가 동시에 호출하면 한 스레드는 lock 을 기다린다. 단일 메서드만 atomic 일 뿐 복합 연산은 race condition 의 여지가 남는다.

두 tx가 각자의 스냅샷에서 '조건 만족' 을 확인하고 서로 다른 row에 UPDATE한다. 둘 다 성공하지만 결합하면 불변량 (최소 1명 on-call) 이 깨진다.

사용자 인증 → 인가 코드 → 액세스 토큰 교환

데이터가 송신 측에서 캡슐화되고 수신 측에서 디캡슐화되는 과정

TCP 연결 수립: SYN → SYN+ACK → ACK

TCP 연결을 안전하게 끊기 위한 4단계 FIN/ACK 교환. 송수신 양방향을 독립적으로 종료한다.

ClientHello → ServerHello+Cert+SKE → ClientKeyExchange+Finished → Finished → 응용 데이터. 두 번의 왕복이 필요하다.

ClientHello + KeyShare → ServerHello + KeyShare + (Encrypted) Cert + Finished → Finished + 응용 데이터. 한 번의 왕복으로 완료.

서버 인증서 → 중간 CA → 루트 CA. 브라우저는 OS/번들에 내장된 루트 CA 까지 체인을 따라가며 서명 검증.

UDP 는 핸드셰이크 없이 즉시 패킷을 송신한다. ACK 없음. 손실되어도 송신측은 모른다. 단순함과 저지연이 핵심.

UDP 패킷은 단 8 bytes 헤더에 4개 필드 (Source Port, Destination Port, Length, Checksum) 만 담는다. TCP 의 20+ bytes 헤더보다 훨씬 가볍다.

네 가지 통신 패턴의 메시지 흐름 차이를 같은 Client/Server 다이어그램에서 차례로 보여준다.

브라우저에서 서버까지의 통신 단계 시각화

Client → Server 의 기본 HTTP 요청-응답 흐름과 상태 코드

브라우저는 도메인당 6개 TCP 연결을 만들어 병렬로 자원을 받는다. 한 연결 안에서는 keep-alive 로 핸드셰이크를 절약하지만, 한 응답이 늦으면 그 뒤가 막힌다.

단 한 개의 TCP 연결 안에서 여러 요청·응답이 stream ID를 가진 frame 으로 동시 진행된다. HPACK 헤더 압축으로 오버헤드도 줄인다.

HTTP/3 는 TCP 대신 UDP 기반 QUIC 을 쓴다. 각 stream 이 독립적이라 한 stream 의 패킷 손실이 다른 stream 에 영향을 주지 않는다. 0-RTT 재접속도 가능.

두 브라우저가 P2P 로 직접 통신하기 위해 거치는 시그널링(SDP offer/answer)과 ICE/STUN 과정, 그리고 확립 후 서버를 거치지 않는 직접 데이터 교환.

캐시에 데이터가 없을 때 DB 조회 + 캐시 갱신 흐름

캐시에 데이터가 있을 때의 빠른 응답 흐름

프로세스가 파일과 소켓을 fd 로 다루는 흐름: open, read/write, socket, close 를 fd 테이블 관점에서 시각화