CS (42) 썸네일형 리스트형 HTTP 버전별 차이점 정리 (0.9 ~ HTTP/3) HTTP는 웹에서 클라이언트와 서버가 데이터를 주고받는 프로토콜이다. 1991년 처음 등장한 이후 꾸준히 발전해왔는데, 각 버전이 어떤 문제를 해결하기 위해 나왔는지를 흐름으로 이해하면 훨씬 쉽게 정리된다. HTTP/0.9 (1991)GET 메서드만 존재응답은 HTML 문서만 가능 (헤더 없음)요청 1건 처리 후 연결 즉시 종료거의 원시적인 수준. 텍스트 한 줄 요청하고 HTML 한 줄 받는 게 전부였다. HTTP/1.0 (1996)헤더(Header) 개념 도입 → 메타데이터 전송 가능GET 외에 POST, HEAD 메서드 추가상태 코드(Status Code) 도입 (200, 404 등)요청마다 새 TCP 연결 생성 → 비효율적헤더가 생기면서 쓸만해졌지만, 매번 새 TCP 연결을 만드는 게 큰 낭비였다... OS 중간고사 대비 보호되어 있는 글입니다. [03/30] 운영체제 멘토링 — Session 1 Introduction to OS + Process + Limited Direct Execution Part 1. Introduction to Operating Systems1.1 프로그램이 실행되면 무슨 일이 일어나는가?OS를 이해하기 전에, 가장 근본적인 질문부터 시작합니다: 프로그램이 실행되면 무슨 일이 일어날까?실행 중인 프로그램은 명령어(instruction)를 실행합니다. 프로세서는 아래 4단계를 끊임없이 반복합니다:┌──────────┐ ┌──────────┐ ┌──────────────────────────────────────┐ ┌──────────────┐│ 1. Fetch │ → │ 2.Decode │ → │ 3. Execute .. [JVM] 내 Java 애플리케이션, 혹시 Serial GC로 동작하고 있진 않을까? Spring Boot 애플리케이션을 Docker 컨테이너에 올려 운영하고 있다면, 한 가지 확인해볼 것이 있다. 바로 GC(Garbage Collector)가 의도한 대로 선택되어 동작하고 있는지다.JVM은 실행 환경의 CPU 코어 수와 물리 메모리를 기반으로 GC를 자동 선택하는 Ergonomics라는 메커니즘을 갖고 있다. 문제는 Docker 컨테이너 환경에서 리소스 제한을 어떻게 거느냐에 따라, 개발자가 의도하지 않은 GC가 선택될 수 있다는 점이다. 1. 서버 클래스와 GC 자동 선택JVM은 실행 환경을 서버 클래스(Server-Class)와 클라이언트 클래스(Client-Class)로 구분하고, 이에 따라 기본 GC를 자동 선택한다. 구분 조건JDK 9+ 기본 GC서버 클래스CPU 2코어 이상 .. [JVM 밑바닥까지 파헤치기] JVM 가비지 컬렉터의 역사 (6) - ZGC와 Generational ZGC: 서브밀리초 GC의 모든 것 이전 포스트에서 Shenandoah가 Brooks Pointer를 사용해 동시 압축을 구현했다면, ZGC는 완전히 다른 접근 방식을 택한다. Colored Pointer와 Load Barrier라는 기법으로 같은 목표를 달성하면서도, 구현 전략은 정반대에 가깝다. 1. ZGC 개요ZGC란?ZGC(Z Garbage Collector)는 JDK 11에서 실험적 기능으로 처음 도입되고, JDK 15에서 프로덕션 레디 상태가 된 저지연(Low-Latency) 가비지 컬렉터다. Oracle이 개발했으며, 'Z'라는 이름에는 특별한 의미가 없다(ZFS 파일시스템에 대한 오마주라고 알려져 있다). ZGC의 핵심 설계 목표는 다음과 같다.초저지연: GC 일시 정지 시간을 서브밀리초(sub-millisecond) 수준으.. [JVM 밑바닥까지 파헤치기] JVM 가비지 컬렉터의 역사 (5) - Shenandoah GC: 동시 이주 실현한 Low-Latency 가비지 컬렉터 서론: 왜 Low-Latency GC가 필요해졌는가하드웨어 성장이 만든 역설1990년대부터 2000년대 초반까지 JVM 힙 메모리는 수백 MB 수준이었습니다. 그러나 메모리 가격 하락과 64비트 아키텍처의 보편화로 상황이 완전히 달라졌습니다. 이제는 수십에서 수백 GB 힙을 사용하는 애플리케이션이 흔합니다. 문제는 Parallel GC 같은 전통적인 처리량 중심 컬렉터에서 발생했습니다. 이들 컬렉터는 힙 크기에 비례해서 Stop-The-World(STW) 시간이 늘어납니다. 4GB 힙에서 100ms였던 Full GC가 64GB 힙에서는 수 초가 걸릴 수 있습니다. 하드웨어가 좋아졌는데 오히려 멈춤 시간은 더 길어지는 역설적인 상황이 된 것입니다. 애플리케이션 특성의 변화현대 애플리케이션은 지연 시간에 훨.. [JVM 밑바닥까지 파헤치기] JVM 가비지 컬렉터의 역사 (4) - G1: 새로운 패러다임 들어가며이전 편에서 CMS의 한계를 살펴봤습니다. Fragmentation, Concurrent Mode Failure, 예측 불가능한 pause time... 이 문제들을 해결하기 위해 완전히 새로운 접근이 필요했습니다. 이번 편에서는 G1(Garbage-First) GC를 다룹니다. Java 9부터 기본 GC가 된 G1은 기존 컬렉터들과 근본적으로 다른 구조를 가집니다. G1의 설계 목표G1은 다음을 목표로 설계되었습니다:예측 가능한 pause time: 목표 시간 내에 GC 완료Compaction 포함: Fragmentation 문제 해결대용량 힙 지원: 수십 GB 힙에서도 효율적CMS 대체: CMS의 장점은 유지, 단점은 해결-XX:+UseG1GC (Java 9부터 기본)-XX:M.. [JVM 밑바닥까지 파헤치기] JVM 가비지 컬렉터의 역사 (3) - 동시성 컬렉터: CMS 들어가며이전 편에서 병렬 컬렉터의 한계를 살펴봤습니다. throughput은 좋아졌지만, STW 자체는 없앨 수 없었습니다. 특히 대용량 힙에서 Major GC가 발생하면 수 초간 멈추는 문제가 있었죠.이번 편에서는 애플리케이션과 동시에 GC를 수행하는 CMS(Concurrent Mark Sweep)를 다룹니다. CMS의 목표CMS의 핵심 목표는 짧은 pause time입니다.Parallel GC: "멈추는 건 어쩔 수 없어. 대신 빨리 끝내자."CMS: "멈추는 시간 자체를 최소화하자. 대부분의 작업은 앱이 돌아가면서 하자."-XX:+UseConcMarkSweepGC CMS의 구조CMS는 Old 영역 전용 컬렉터입니다. Young 영역은 ParNew가 담당합니다.┌───────────────────.. 이전 1 2 3 4 ··· 6 다음
