본문 바로가기

내 이야기

(675)
TCP Handshake에서 보이는 window size / wscale 값, win 값 TCP Window size란?TCP에서 window size(win)는 수신 측이 “내가 지금 더 받을 수 있는 버퍼 여유”를 광고(advertise)하는 값입니다.win이 크다 → 수신 측 버퍼 여유가 많다 → 송신 측이 더 많이 보낼 수 있다win이 작다 → 수신 측 버퍼 여유가 적다 → 송신 측이 천천히 보내야 한다 즉, win은 네트워크 장비의 “대역폭” 같은 개념이 아니라, TCP 수신 버퍼(흐름 제어) 관점의 값입니다. 왜 wscale(Window Scaling)이 필요할까?TCP 헤더의 window 필드는 16비트라서 최대가 65,535입니다.요즘 환경(클라우드, DC, 고대역폭/지연 구간 등)에서는 64KB로는 부족할 수 있기 때문에, TCP는 Handshake(SYN / SYN-ACK)..
AWS Regional NAT Gateway Today Keys : aws, vpc, nat, gateway, regional, network, architecture, high-availability이번 포스팅은 AWS에서 25년 11월 19일에 새롭게 발표한 Regional NAT Gateway에 대한 소개입니다.기존 NAT Gateway는 특정 가용영역(Availability Zone)에 종속적인 자원이기 때문에각 가용영역별로 NAT Gateway를 구성하여, 가용성을 확보하거나 가용영역을 교차하여 사용을 했습니다.Regional NAT Gateway는 가용 영역이 아닌 리전 종속적인 자원으로가용 영역 전체에 걸쳐 자동으로 확장/축소되며 동작하는 NAT Gateway입니다.AWS Regional NAT Gateway란?하나의 NAT Gate..
Linux에서의 이름 해석(Name Resolution) 경로 이해하기 Today Keys : linux, name, resolution, domain, query, dns, ip, glibc, nss, resolver, 질의리눅스(Linux)의 이름 해석(Name Resolution) 경로구분내용동작 방식시스템 해석기 경로gblic + NSS(Name Service Switch)운영체제의 표준 경로로, /etc/nsswitch.conf 규칙에 따라서 지정된 순서대로 질의 수행DNS 직접 질의라이브러리에서 자체 질의 수행운영체제 표준 경로와 상관 없이, /etc/resolv.conf에 선언된 DNS 서버로 직접 질의 수행 시스템 해석기 경로 (glibc + NSS)운영체제의 공식 이름 해석(Name Resolution) 체계/etc/nsswitch.conf 파일의 hosts..
TLS SNI(HTTP SNI) 테스트 환경 구성 및 동작 방식의 이해 Today Keys : tls, sni, https, encrypt, certbot, aws, 인증서, ssl, server, name, indication 이번 포스팅에서 TLS SNI 테스트 환경을 구성하고 테스트하면서 TLS SNI에 대한 동작 방식 이해를 해보는 포스팅입니다. 먼저 포스팅에 앞서서 용어부터 정리하면, 흔히 “HTTP SNI”라고 부르지만, SNI(Server Name Indication)는 HTTP 기능이 아니라 TLS ClientHello(핸드셰이크) 확장입니다. TLS 자체만으로는 “클라이언트가 어느 서버 이름(도메인)에 접속하려는지” 서버가 알 방법이 없어서, 가상호스팅(한 IP에 여러 HTTPS 사이트)에서 문제가 생기는데, SNI가 그 정보를 전달해줍니다. 이번 포..
RHEL에서의 DNS Cache, 그리고 systemd-resolved 이야기 2 이번 포스팅은 지난 포스팅이었던 RHEL에서의 DNS Cache, 그리고 systemd-resolved 이야기 1 에서 다루지 못한 몇 가지 개념 내용을 몇 가지 정리해 보려고 합니다. glibc (GNU C Libriary)리눅스 시스템에서 대부분의 프로그램이 사용하는 표준 C 라이브러리대부분의 사용자 명령어(ping, ssh, curl 등)는 내부적으로 glibc를 통해 시스템 콜(System Call) 을 호출즉, 운영체제 커널과 애플리케이션 사이의 표준 인터페이스 계층 역할을 수행getaddrinfo()는 glibc에 포함된 함수로, 내부적으로 NSS(Name Service Switch) 모듈을 호출하여이름 해석(Name Resolution, 이름 조회) 을 수행함 glibc NSS (Name S..
RHEL에서의 DNS Cache, 그리고 systemd-resolved 이야기 1 Today Keys : dns, cache, 도메인, 캐시, rhel, systemd-resolved, query, 질의, redhat이번 포스팅에서는 RHEL(Redhat Enterprise Linux)에서의 DNS Cache에 대한 내용입니다. Linux Distro에 따라 현재 DNS Cache 사용이 다를 수 있기 때문에, 사용 중인 Linux에 따라서 어떻게 동작하는지 알아두면 좋을 듯 하여, 간단히 정리해 보았습니다. 관련하여, 작년에 포스팅 한 아래의 글들도 읽어보시면 좋을 것 같습니다. DNS 동작 이해를 위한 기술 - Netplan Part 1DNS 동작 이해를 위한 기술 - Netplan Part 2DNS 동작 이해를 위한 기술 - Netplan Part 3Linux에서 DNS 질의(Q..
[HTTP 이해하기 1편] 왜 지금 HTTP/1.1과 HTTP/2를 함께 봐야 할까 today keys : HTTP, HTTP/1.1, HTTP/2, 웹 통신, Apache httpd, TLS, ALPN, 브라우저 협상, 패킷 분석웹 서비스를 운영하다 보면 HTTP라는 단어는 이미 너무 익숙해서 깊게 생각하지 않고 지나가게 됩니다. 브라우저로 웹사이트에 접속하고, 서버가 응답을 반환하는 흐름이 너무 자연스럽기 때문입니다. 그런데 같은 웹 접속처럼 보여도 내부에서는 HTTP/1.1로 동작할 수도 있고 HTTP/2로 동작할 수도 있습니다.이번 포스팅에서는 이 두 프로토콜을 함께 봐야 하는 이유와 앞으로 이 시리즈가 어떤 흐름으로 전개될지를 먼저 정리합니다.HTTP/1.1은 여전히 현재진행형HTTP/1.1은 단순히 "예전 버전"이 아닙니다.RFC 9112는 HTTP/1.1을 메시지 문법, 메..
SSH 접속 과정 단계역할진행 내용RFC사용 프로토콜/암호화 예시1. TCP 연결기본 통신 채널 수립- 클라이언트가 서버(기본 22/tcp)에 연결 - TCP 3-way handshake 완료 후 통신 가능 상태RFC 4251 (Overview)TCP/IP (전송 계층)2. 프로토콜 버전 교환SSH 버전 호환성 확인- 클라이언트/서버가 지원하는 SSH 버전 교환 - 일반적으로 SSH-2.0 사용RFC 4253 (Transport Layer Protocol)SSH-2.0-OpenSSH_8.73. 알고리즘 협상 (KEXINIT)암호화 매개변수 합의- 지원 가능한 암호 알고리즘 목록 교환 - 키 교환(KEX), 대칭 암호, MAC, 압축 방식 합의RFC 4253- KEX: diffie-hellman-group14-sha256,..