HTTP가 RFC를 엄격히 준수하는 이유HTTP가 RFC(Requests for Comments)라는 엄격한 표준을 따르는 이유는 상호운용성(interoperability) 때문이다. 파편화 방지만약 구글 크롬이 A라는 방식으로 요청을 보내고, 네이버 서버는 B라는 방식만 이해한다면 웹은 동작하지 않는다.전 세계 수억 개의 서버와 클라이언트가 문제 없이 통신하려면 공용어(Standard)가 필수적이다. 중간 매개체의 존재사용자가 웹사이트에 접속할 때 브라우저와 서버만 있는 게 아니다.그 사이에는 수많은 프록시(Proxy), 캐시 서버, CDN, 방화벽 등이 존재한다. 이 모든 장비가 RFC 표준을 따르고 있어야만 데이터가 중간에 왜곡되지 않고 전달된다. 그 외 사유구분내용확장성HTTP/1.1에서 HTTP..
Backend
개요네트워크 서버를 개발할 때 가장 먼저 고민하게 되는 것은 "수많은 연결(Connection)을 어떻게 효율적으로 관리할 것인가?"이다. 이번에 진행한 HTTP 서버 프로젝트 또한 복잡한 계산보다는 데이터를 읽고 쓰는 I/O 작업 위주인 전형적인 I/O-bound 서버였다. Connection 단위로 상태를 가진다. { keep-alive, idle timeout, 여러 request 처리 }I/O가 대부분이다. { accept(), read(), write() }요청 처리 시간이 짧고 예측 가능하다.동시에 여러 connection을 다룬다.CPU-bound 작업은 거의 없다. 본 게시글에서는 전형적인 Thread-per-connection 모델의 한계를 살펴보고, Kotlin의 Coroutine이 어..
개요프레임워크를 사용하면 HTTP 서버는 쉽게 만들 수 있다. 하지만 "왜 이렇게 설계되어 있는지"는 파악하기 어렵다. 이번 프로젝트는 TCP 소켓 위에서 HTTP/1.1 서버를 직접 구현하며, 각 계층이 가지는 책임과 데이터의 흐름을 파악하는 데 중점을 두었다. 전체 구조 (Architecture)서버는 단순히 하나의 커다란 코드가 아니라, 서로 다른 책임을 가진 5개의 핵심 계층으로 구성된다.Server : TCP 연결 수락 및 Coroutine 기반 Connection 관리RequestParser : 스트림(Bytes)을 분석하여 의미있는 객체(HttpRequest)로 변환HTTP Models : 요청과 응답의 상태를 정의하는 도메인 모델Routing & Handler : URL에 맞는 로직을 찾아..
DNS over QUIC(DoQ)로 보는 Layered architecture와 프로토콜 설계 원칙1. DoQ 스택으로 보는 현대 프로토콜의 계층화 구조DNS over QUIC (DoS)는 전형적인 Layered Architecture 사례다.개념적으로 보면 UDP ⊃ QUIC ⊃ TLS ⊃ HTTPS ⊃ DNS 구조를 통해, 각 계층은 자신의 역할만 수행하고 상위 계층의 데이터를 페이로드로 운반한다. 이 구조의 핵심은 역할 분리와 교체 가능성이다.DNS는 전송 방식이나 암호화 방식이 바뀌어도 논리 자체는 유지된다. 현대 서버 환경에서 최소 3단 이상의 계층을 사용하는 이유는 보안, 확장성, 운영 유연성을 동시에 확보하기 위함이다. 게임은 예외적으로 1단 프로토콜을 사용하는데, 이 표현은 암호화나 보안을..
서론 : 왜 BitTorrent 인가? HTTP / FTP 같은 전통적인 프로토콜은 서버 한 대가 수만 명의 클라이언트에게 파일을 보내야 했다.사람이 몰릴 수록 서버에는 부하가 발생해 성능과 속도가 모두 저하되었는데, 이를 트래픽 병목 현상이라고 한다. BitTorrent는 이 문제를 역발상으로 해결했다. 파일을 받는 클라이언트가 동시에 주는 역할도 수행하게 만든 것이다."모두가 서버이자 클라이언트가 되는 것", 이것이 BitTorrent가 추구하는 P2P(Peer-to-Peer) 철학의 핵심이다.1. Bittorrent 구성 요소 (The Swarm)BitTorrent 네트워크에 접속하는 순간부터 해당 클라이언트는 하나의 거대한 생태계인 Swarm의 요소가 된다. 이 요소는 세 부류로 나뉜다.Seed..
1. 개요기존에 구현하던 TCP 기반 채팅 애플리케이션에 파일 전송 기능을 추가하면서, 단순히 "파일을 전송하는 것" 이상의 문제가 발생했다.채팅(JSON)과 파일(binary)이 동일한 TCP 연결을 공유한다는 점대용량 파일(10GB 이상) 전송 중에도 채팅은 끊기지 않아야 한다는 요구그리고 무엇보다 메모리 폭주 없이 안정적으로 동작해야 한다는 제약 이 글에서는 TCP 스트림의 특성으로 인해 발생한 문제를 어떻게 인식했고, 어떤 프로토콜과 구조로 해결했는지를 단계적으로 정리한다.GitHub 주소 : https://github.com/proLmpa/ChatApp2. 요구사항 정의정리된 요구사항은 다음과 같다.N:N 채팅방 환경'/f ' 명령어를 통해 특정 사용자에게 파일 전송서버는 저장소가 아닌 전달자..
이 글은 Mozilla의 "Evolution of HTTP" 원문을 번역한 글에 구글링을 통해 찾은 정보를 추가한 게시글입니다.참고한 블로그들은 하단의 참고 자료에 추가하였으니 세부 정보를 파악하는데 도움이 되었으면 좋겠습니다. HTTP Protocol의 시작HTTP (HyperText Transfer Protocol)는 www의 기반 프로토콜이다. 1989년부터 1991년까지 Tim Berners-Lee와 그의 팀이 개발한 HTTP는 유연함을 형성하는 동시에 단순함을 지키는 많은 변화를 거쳤다. 기존의 TCP와 IP 프로토콜을 거쳐 개발된 HTTP는 아래의 4가지 요소로 구성된다.HyperText Markup Language (HTML) : Hypertext 문서를 대표하는 본문 양식HyperTe..
1. Primitive 와 ReferenceJVM 환경Primitive type (원시 타입)int, long, float, double, boolean, char, byte, short스택 / 레지스터 위주, null 불가객체가 아니라 값(value)으로만 다룸.Reference type (참조 타입)Integer, Long, Float, String, List, Any 등 모든 객체 타입힙(Heap)에 객체가 존재하고, 변수에는 그 객체를 가리키는 참조(주소)가 들어감null 가능Kotlin 입장Kotlin 언어 자체는 "primitive"라는 말은 쓰지 않고, nullable 여부로만 type을 나눈다.Int, Long, Float, BooleanKotlin 레벨에선 그냥 값 처럼 보이는 것들nul..
멀티 모듈 기반의 Kotlin 프로젝트(Server/Client/Share)를 구성하고, 각 모듈에 com.github.johnrengelman.shadow 플러그인을 적용하여 Fat JAR 형태로 빌드했다. 빌드는 성공했지만, 실행 시 아래 오류가 발생했다.C:\ java -jar .\Server\build\libs\Server-1.0-SNAPSHOT.jar.\Server\build\libs\Server-1.0-SNAPSHOT.jar에 기본 Manifest 속성이 없습니다. 즉, Manifest 내부에 Main-Class 속성이 존재하지 않아 실행 가능한 JAR로 인식되지 않는 상황이다. 이번 글에서는 아래 사항들을 실무 관점에서 정리한다.🎯 왜 이 문제가 발생했는지🎯 무엇을 잘못 설정했는지🎯 ..
1. 접근 제어자 : internal, openJava는 클래스가 기본적으로 상속 가능한 상태 (open)이지만, Kotlin은 기본이 final이다.이 설계는 "명시적으로 허용한 경우에만 상속하도록" 하여 설계 안정성을 높이기 위함이다. - final (Java) : 변수 수정 및 methods/classes overriding 방지 - final (Kotlin) : overriding & 상속 방지 Kotlin의 주요 접근 제어자는 다음과 같다.public : 모듈 어디서나 접근 가능internal : 같은 모듈 내부에서만 접근 가능protected : 상속 관계에서만 접근 가능private : 해당 파일 또는 클래스 내부에서만 접근 가능open : 상속을 명시적으로 허용하는 키워드 또한 Kotlin..
