HTTP/3 HTTP/3 기존의 HTTP/1.1, HTTP/2와는 달리, UDP 기반의 프로토콜인 QUIC를 기반으로 통신하는 프로토콜 TCP는 3-way handshake를 수행하기 때문에 속도가 느림 TLS 상의 TCP인 경우에는 추가적인 시간이 더 소요됨 HTTP/2는 이 handshake의 횟수를 줄인 것이지 handshake의 속도 자체는 오래 걸렸음 또한 TCP는 HOL blocking 문제를 가짐 HTTP/2 는 HTTP 단에서의 HOL blocking 문제는 해결했지만, TCP 단계의 HOL blocking 문제는 해결 불가 이런 이유로 커스터마이징이 용이한 UDP를 이용한 HTTP/3 및 QUIC가 등장 장점 TLS + TCP를 사용하는 경우, 연결에 3RTT가 소요되나, QUIC는 연결에 1RTT만 소요됨 첫 번째 handshake 시 연결 / 암호화 정보 및 데이터를 그냥 다 보내 버리기 때문 한 번 연결이 성공하면, 설정을 캐싱하고, 이후 요청이 들어오면 바로 연결하기 때문에 0RTT가 소요됨 QUIC는 패킷 번호 공간을 별도로 사용해서, 어떤 패킷을 재전송해야 하는 지에 대한 모호성을 없앰 패킷 손실 감지가 쉽고 빨라짐 하나의 연결에서 여러 데이터를 보내는 멀티플렉싱이라는 방법을 통해 효율적으로 데이터를 보냄 TCP의 경우 IP, Port로 연결을 식별하지만, QUIC는 커넥션 ID라는 정보를 이용해 연결을 식별 클라이언트의 IP 주소가 변경되더라도, 계속 기존의 연결을 유지 가능 TCP를 이용한다면 새로 handshake를 해야 함 References https://evan-moon.

HTTP/2 HTTP/2 HTTP/2 는 HTTP/1.1의 확장으로, HTTP/1.1과의 호환성을 유지하면서 성능 향상에 신경 쓴 프로토콜 다음과 같이 성능 위주의 기능들이 추가됨 Multiplexed Streams 하나의 TCP 연결을 통해 여러 데이터에 대한 요청을 병렬로 전송 가능 데이터에 대한 응답을 요청 보낸 순서대로 받기 때문에 대기 시간이 늘어나는 HOL Blocking 문제를 해결 가능 웹 사이트를 로드하는 데 걸리는 시간이 줄어듦 중복 헤더 제거 / 헤더 압축 클라이언트 / 서버에서 이전 요청에 사용된 헤더를 가지고 있음 이를 이용해 중복된 내용의 헤더를 보내는 경우 생략해도 됨 이외에도 HPack이라는 방식으로 헤더를 압축하기 때문에, 헤더 크기가 굉장히 줄어듦 Binary Protocol 기존에는 텍스트를 통해 데이터를 전송했다면, HTTP2에서는 바이너리 데이터로 통신하도록 변경 오류가 발생할 가능성이 적으며, 텍스트의 특성을 활용한 보안 위협 공격을 방어 가능 Server Push 서버 단에서 아직 요청받지는 않았지만, 향후 요청에서 예상되는 정보를 클라이언트에 전송 가능 리소스 A가 리소스 B를 참조하면, 클라이언트가 A를 요청할 때 B를 같이 보냄 Stream Priorization 클라이언트가 리소스들에 대한 요청을 보낼 때 가중치를 지정해서 선호하는 응답을 우선 순위로 받을 수 있음 서버는 우선 순위가 높은 요청을 우선적으로 보내도록 조정 References https://gngsn.

Multi Server Session Storage Multi Server Session Storage 여러 서버(WAS) 에서 세션 저장소를 사용하는 방법에는 여러 방법이 존재 이 때 각각의 WAS가 독립적인 세션 저장소를 사용하는 경우, 데이터의 불일치가 발생함 (정합성 문제) 이를 해결하기 위해 다음과 같은 여러 가지 방법 존재 Sticky Sesstion 세션을 고정시키는 방법으로, 로드 밸런서가 어떤 사용자의 요청을 처리하는 서버를 고정시키는 것 어떤 서버에 요청을 보낼 지는 쿠키를 확인하면 됨, L7에서 동작 세션이 유지되는 동안 동일한 서버와 통신하므로, 다른 웹 서버의 세션 저장소와의 정합성을 고려하지 않아도 됨 그러나 다음과 같은 단점 존재 로드 밸런싱이 제대로 수행되지 않고 특정 서버에 몰릴 수 있음 한 서버가 죽는 경우 해당 서버를 이용하는 사용자는 세션 정보를 잃어버림 (Stateless하지 않아서 생기는 문제) Session Clustering Tomcat에서 사용하는 방법 각 서버의 세션 저장소에 변경된 사항이 발생한 경우, 해당 내용을 다른 서버의 세션 저장소에 모두 복사하는 방법 이후 다른 서버에 접속하더라도, 세션 정보가 복제되어 있으므로 정합성 문제를 해결 가능 또한 로드 밸런싱 역시 가능하며, 한 서버가 죽어도 운영 가능 그러나 다음과 같은 단점 존재 모든 서버가 동일한 내용을 가져야 하므로, 많은 메모리가 필요 또한 내용이 바뀔 때 마다 모든 서버의 값을 업데이트 해야 하므로, 서버 수에 비례해 트래픽이 증가 별도의 Session Storage 각 서버마다 세션 저장소를 가지는 것이 아닌, 모든 서버마다 하나의 세션 저장소를 이용하는 방법 한 서버가 장애가 발생해도 문제가 없으며, 정합성도 문제가 되지 않고, 값을 복제할 필요도 없음 또한 세션 저장소는 데이터 소멸에 따른 피해가 비교적 적기 때문에, 세션 저장소로 In-memory DB를 사용하는 것이 좋음 그럼에도 하나의 세션 저장소는 Single Point of Failure가 될 수 있음 이를 방지하기 위해 master-slave 구조 등을 활용해 서비스 장애시 slave DB를 master DB로 승격시켜 장애를 해결 가능 References https://hyuntaeknote.

GSLB GSLB Global Server Load Balancing의 약자 Round Robin DNS 로드 밸런싱의 약점을 극복하기 위해 등장한 발전된 로드 밸런싱 서비스 근본적으로는 DNS의 형태를 띔 Health check GSLB vs DNS 로드 밸런싱 구분 DNS GSLB Health check 하지 않음, 장애가 난 서버의 IP 주소 반환 가능 수행, 장애 서버는 응답 목록에서 제외 트래픽 특정 서버에 몰릴 수 있음 트래픽이 몰리는 서버의 주소는 반환하지 않음 지연 시간 / 지역 정보 고려하지 않음 가장 가깝고 지연 시간이 적은 서버 주소 반환 References https://skstp35.

DNS Load Balancing DNS Load Balancing 별도의 하드웨어나 소프트웨어가 아닌 DNS를 통해 트래픽을 분산하는 로드 밸런싱 기법 서버에 요청을 보내기 위해서는 서버의 IP 주소를 알아야 함 IP 주소를 알기 위해서는 DNS를 사용해야 되기 때문 Round Robin 방식으로 순서대로 돌아가면서 여러 서버 중 한 서버의 IP를 반환 간편하게 서로 다른 서버의 부하를 분산 가능 서버가 서로 다른 스펙일 경우 가중치를 이용해서 분산 비율을 변경해야 함 장단점 장점 중간 장비가 필요하지 않음 간편하고, 비용이 비교적 덜 듦 단점 서버의 수 만큼 IP 주소 필요 Health check를 하지 않기 때문에, 장애가 난 서버의 IP를 반환할 수 있음 DNS 결과로 얻은 IP 주소를 캐싱하기 때문에, 균등하게 부하가 분산이 되지 않음 References https://jaehoney.

L4 L7 Load Balancer Load Balancer 로드 밸런서는 트래픽을 여러 대의 서버에 분산 시키는(로드 밸런싱을 수행하는) 하드웨어 / 소프트웨어 L4 로드 밸런서와 L7 로드 밸런서 존재하며, 로드 밸런싱을 위해 사용하는 정보가 다름 L4 Load Balancer 4계층에서 IP와 Port 정보를 바탕으로 로드 밸런싱 수행 4계층의 정보 까지만 보면 되므로, 속도가 빠르고 효율이 높음 섬세하게 부하를 분산하기는 어려움 L7 Load Balancer IP, Port 정보 외에 HTTP URI, 헤더, 쿠키 등등의 정보를 사용해 로드 밸런싱 수행 요청의 세부적인 사항을 확인해서, 각 요청에 맞는 서비스의 서버에 요청을 보내면 됨.

Load Balancing Load Balancing 서버가 처리해야 할 요청(Load)를 여러 대의 서버로 나눠(Balancing) 처리하는 것 Scale-out을 통해 여러 서버를 사용할 경우 필수적 라운드 로빈 등 여러 로드밸런싱 기법 존재 로드 밸런싱을 수행할 때 사용하는 정보에 따라 L4 / L7 로드 밸런싱으로 구분됨 로드 밸런싱 기법 라운드 로빈 서버에 들어온 요청을 순서대로 돌아가며 배정 여러 대의 서버가 동일한 스펙을 가짐 서버와의 연결이 짧을 때 유용 가중 라운드 로빈 서버의 트래픽 처리 능력이 상이한 경우 사용 가능 각 서버마다 가중치를 두어 가중치가 높은 서버에 요청을 우선적으로 배분 IP 해시 방식 사용자의 IP 주소를 해시한 값을 이용해 특정 서버에 매핑 사용자는 항상 동일한 서버로 연결됨 최소 연결 방식 요청 시점에서 가장 적은 연결 상태를 가진 서버에 연결 트래픽 배분이 고르지 않은 경우 적절 최소 응답 방식 서버의 연결 상태와 현재 응답 시간을 고려해 연결 가장 적은 연결 상태와 짧은 응답 시간을 보이는 서버에 우선적으로 요청을 배분 References https://tecoble.

Nginx Apache 차이 Nginx Apache 차이 Apache 서버는 클라이언트의 connection 요청이 들어오면 프로세스를 생성 다만 프로세스를 만드는 시간이 오래 걸리므로, 미리 프로세스를 생성해 두는 prefork 방식 사용 그러나 이 방법은 동시에 연결된 커넥션이 만 개 이상으로 많아지는 경우 메모리 고갈 문제 발생 기하급수적인 context switching이 발생하며 더 이상 커넥션이 생성되지 않는 C10K 문제가 생김 Apache 서버의 확장성은 좋음 NGINX는 아파치 서버의 부족한 부분을 보완하기 위해 등장한 웹 서버 아파치 서버 앞에서 동시 커넥션을 nginx가 담당 마스터 프로세스 밑에 여러 자식 프로세스를 만들어 비동기 논블로킹 방식으로 처리 Event가 발생할 때 마다 처리하는 event-driven 구조의 웹 서버 확장성은 apache보다 안 좋지만, 성능이 좋음 References https://blog.

CORS Preflight CORS Preflight 브라우저가 HTTP 요청을 보내기 전에, 먼저 보내는 요청 OPTIONS 메소드로 자신이 이후에 보낼 HTTP 요청에 대한 정보를 헤더에 담아서 보냄 Access-Control-Request-Headers: 본 요청에서 사용할 헤더 정보 Access-Control-Request-Method: 본 요청에서 사용할 메소드 Origin: 요청을 보내는 Origin 서버는 이에 대한 응답으로 다음과 같은 응답을 헤더에 담아 반환 Access-Control-Allow-Origin: 허용하는 origin 정보 Access-Control-Allow-Methods: 허용하는 method들 정보 이 결과를 보고 브라우저가 CORS 정책 위반을 판단 CORS 정책 위반인 요청은 보내지 않으므로, 리소스 낭비를 막을 수 있음 브라우저가 서버에 자동으로 보내주기 때문에, 프론트엔드 개발자가 요청을 직접 작성할 필요는 없음 특정 조건을 만족시키는 단순 요청의 경우에는 생략됨 Preflight 요청에 대한 결과는 일정 기간동안 캐싱됨 References https://developer.

HTTP 기본 지식 -김영한 - 모든 개발자를 위한 HTTP 웹 기본 지식 강의 내용 일부 정리 HTTP HTTP는 hypertext를 전송하기 위한 프로토콜 현재는 모든 형태의 데이터를 HTTP로 보냄 이미지, HTML, JSON, 파일 등등 HTTP 버전별 역사 0.9: 1991년, GET 메서드만 지원, 헤더 X 1.0: 1996년, 메서드, 헤더 추가 1.1: 1997년, 가장 많이 사용되는 버전, 2014년에 개정 2: 2015년, 성능 개선 3: 진행 중, UDP 사용해 성능 개선 HTTP 특징 클라이언트 - 서버 구조 Stateless 비연결성 HTTP 메시지를 활용해 통신 단순하고, 확장이 쉬움 (크게 성공한 이유) Stateless 서버가 클라이언트의 상태(state)를 보존하지 않음 중간에 서버가 바뀌어도 되므로 서버 확장성이 높아짐 클라이언트가 데이터를 더 보내야 함 그러나 실제로는 로그인 등의 상태는 유지되어야 하므로, 쿠키 / 세션등을 활용해 일부 상태는 유지 비연결성 요청에 대한 응답을 보내고 연결을 끊음 서버 자원을 효율적으로 사용 가능 그러나 TCP/IP 연결을 매번 새로 맺어야 한다는 단점 존재 지금은 HTTP 지속 연결을 사용해 문제를 해결 HTTP 2, 3에서 더욱 최적화됨 HTTP 메시지 모든 형태의 데이터를 HTTP 메시지에 담아 전송 요청 / 응답 메시지가 존재하고, 시작 라인, 헤더, 바디로 구성됨 시작 라인: 메시지 가장 윗 줄 요청 메시지: HTTP 메서드, 요청 대상, HTTP 버전으로 구성 응답 메시지: HTTP 버전, HTTP 상태 코드, 이유 문구로 구성 헤더: 필드 이름: 필드 값 의 쌍으로 구성되며, HTTP 전송에 필요한 부가 정보가 담김 바디: 실제 전송할 데이터가 들어가며, byte로 표현 가능한 모든 데이터 전송 가능 HTTP Method HTTP Method의 필요성 HTTP로 API를 만들기 위해서는 URI를 설계해야 함 URI에는 리소스만 매핑하는 것이 좋음 리소스로 어떤 행위를 할 지는 HTTP Method로 분리하면 됨 HTTP Method 종류 GET: 리소스 조회 POST: 요청 데이터 처리 (주로 등록) PUT: 리소스를 대체 PATCH: 리소스의 일부분을 변경 DELETE: 리소스 삭제 이외에도 HEAD, OPTIONS, CONNECT, TRACE 등 존재 GET: 조회 서버에 전달하고 싶은 데이터는 쿼리 스트링을 통해 전달 메시지 바디를 통해 데이터 전달이 가능은 하지만, 지원하지 않는 서버가 많음 그렇기 때문에 쿼리 스트링으로 데이터를 전달해야 함 POST: 처리 메시지 바디를 통해 서버로 요청 데이터를 전달 서버는 요청 데이터를 받아 처리 주로 신규 등록 및 프로세스 처리 등을 담당.