[컴퓨터 네트워크]애플리케이션 레이어

HTTP

HTTP 프로토콜이란?

HTTP(Hypertext Transfer Protocol)

• HTTP는 World Wide Web 에서 정보를 주고 받을 수 있게 해주는 프로토콜이다.
• 웹에서 송수신되는 정보는 HTML, CSS, JS, 이미지 등이 있다.
• HTTP는 TCP 기반에서 동작하며, 80번 포트를 사용한다.(HTTP3는 UDP 기반에서 동작한다.)

HTTP의 요청/응답 모델에 대해

 

• REQUEST(요청)

HTTP 요청은 클라이언트가 서버에 보내는 메시지이다.

Start line

• 첫 번째 요소
  • HTTP method를 나타낸다.
  • HTTP method를 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD, OPTIONS)을 설명한다.
• 두 번째 요소
  • 요청 대상(일반적으로 URL 이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성된다.

HTTP 메소드 중 GET과 POST의 차이점

• GET: 서버에게 데이터를 요청하는 것.
• POST: 클라이언트에서 서버로 데이터를 전송하는 것.

HTTP 메소드 중 PUT과 PATCH의 차이점

• PUT: 서버 데이터를 수정하는 요청. 수정 요청한 컬럼을 제외한 ROW의 다른 값들 모두 NULL로 바꿈
• PATCH: 서버 데이터를 수정하는 요청. PUT 요청과 다르게 정확히 수정 요청한 값만 수정.

HTTP 상태 코드

• 모든 HTTP 응답 메시지는 HTTP 상태 코드와 함께 반환된다.
• 상태 코드는 클라이언트에게 요청이 성공했는지, 실패했는지, 추가 조치가 필요한지 등을 알려주는 3자리 숫자

 

 

HTTP 상태 코드 설명

200 (ok)	요청 성공
201 (Moved Parmanently)	요청 객체가 영원히 이동됨
400 (Bad Request)	서버가 요청을 이해할 수 없음
404 (Not Found)	서버에서 요청받은 리소스를 찾을 수 없음
505 (HTTP Version Not Supported)	요청 HTTP 프로토콜 버전을 서버가 지원하지 않는다.

HTTP 헤더란?

HTTP 헤더는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해준다.

 

 

HTTP/1.1 표준 기준으로 4가지로 분류됨

1. General Header: 요청과 응답에서 사용할 수 있는 공통 헤더
2. Request Header: 페치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더.
3. Response Header: 서버 → 클라이언트 정보 전달 헤더
   1. Server:서버 소프트웨어 정보
   2. Set-Cookie: 쿠키 생성/수정
   3. WWW-Authenticate: 인증 필요 시 인증 방식 알림
   4. Location: 리다이렉트 주소(3xx 응답에서 사용)
4. Entity Header: body의 내용을 설명하는 헤더

HTTP의 무상태성

• HTTP 는 서버가 클라이언트의 상태를 보존하지 않는 무상태 프로토콜
• 장점: 서버 확장성 높음. 무한한 서버 증설 가능(스케일 아웃)
• 단점: 클라이언트가 추가 데이터를 전송해야 함(서버에 저장되어 있지 않으므로)
• 단순한 서비스 소개 화면 같은 경우엔 무상태로 설계할 수 있지만, 로그인 등 유저의 상태를 유지해야 하는 서비스라면 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지해야 한다.

HTTP Keep-Alive 란

HTTP 는 Connectionless 방식으로 연결을 매번 끊고 새로 생성하는 구조이다. 이는 Network 비용 측면에서 최초 연결을 하기 위해 많은 비용을 소비한다.

HTTP 프로토콜의 Keep-alive 기능은 클라이언트와 서버 간 요청 및 응답 과정을 효율적으로 유지하기 위해 사용된다. Keep-Alive 를 활성화하면 하나의 TCP 연결을 여러번 재사용하며 응답과 요청을 수행할 수 있다.

HTTP 프로토콜에서 클라이언트와 서버 간 여러 요청을 단일 TCP 연결을 재사용하는 방식으로 처리하는 기능을 말한다. HTTP/1.1 프로토콜부터 도입됐다. 이 기능을 활성화하면 여러 HTTP 요청 및 응답 과정에서 발생하는 네트워크 오버헤드를 줄일 수 있다.

keep-alive를 사용하는 경우 HTTP 요청 헤더에 Connection: Keep-Alive 라는 값을 포함시킨다.

HTTP/1.1 200 OK
Connection: Keep-Alive
...

(body)

• 사용 상 이점

keep-alive가 없으면 클라이언트와 서버는 각 요청과 응답에 대해 매번 새로운 TCP 연결을 생성하고 닫아야 한다. 이 방식은 네트워크 리소스가 비효율적으로 사용된다. 반면 keep-alive를 사용하면 단일 TCP 연결에서 여러 요청과 응답이 이루어지기 때문에 네트워크 지연 시간이 줄어들고 웹 사이트 성능이 좋아진다.

초기 HTTP/1.0 프로토콜에서는 각 HTTP 요청에 대해 매번 TCP 연결을 새로 생성해야 했기 때문에 위에서 언급한 문제들이 존재했다. 이를 해결하기 위해 HTTP/1.1 프로토콜에 해당 기능이 도입됐다.

 

 

위 이미지는 4개의 커넥션이 생성되어 각각 처리하는 방식과 하나의 커넥션으로만 처리하는 방식을 나타낸 것이다.

Keep-Alive에서는 커넥션을 맺고 끊는 데 작업이 없어졌기 때문에 시간이 단축된다.

HTTP 파이프라이닝

파이프라이닝(Pipelining)은 주로 네트워크 프로토콜에서 사용되는 기법으로, 여러 요청을 동시에 보내고, 응답을 기다리지 않고 계속해서 추가적인 요청을 보내는 방식이다. 이를 통해 대기 시간을 줄이고 네트워크 효율성을 높일 수 있다.

• 파이프라이닝의 동작 방식

기본적으로, 파이프라이닝은 클라이언트가 서버로 여러 요청을 연속적으로 보내는 방식을 의미한다. 이를 통해 클라이언트는 첫 번째 요청에 대한 응답을 기다리지 않고, 다음 요청들을 전송할 수 있습니다. 서버는 이러한 요청들을 차례대로 처리한 후, 응답을 클라이언트에게 순차적으로 반환합니다.

이 방식은 네트워크 대기 시간을 줄이는 데 도움이 됩니다. 일반적인 HTTP 요청/응답 사이클에서는 요청을 보내고 응답을 받은 후 다음 요청을 보낼 수 있지만, 파이프라이닝을 사용하면 응답을 기다릴 필요 없이 여러 요청을 한 번에 보내므로 전체 응답 시간을 줄일 수 있습니다.

• HTTP/1.1에서의 파이프라이닝
  • HTTP/1.1은 기본적으로 파이프라이닝을 지원합니다. 클라이언트는 같은 연결에서 여러 HTTP 요청을 연속적으로 전송할 수 있습니다.이때, 클라이언트는 첫 번째 요청에 대한 응답을 기다리지 않고 두 번째, 세 번째 요청을 계속 보냅니다.
• 파이프라이닝의 한계
  • 순차적인 응답 처리: 파이프라이닝은 여러 요청을 보내더라도 응답은 순차적으로 처리된다. 즉, 첫 번째 요청의 응답이 완료되어야 두 번째 요청의 응답을 처리할 수 있다. 만약 첫 번째 요청이 지연되면 그 뒤의 요청들도 응답이 지연되는 문제가 발생하는데, 이를 Head-of-Line-Blocking 이라고 한다.
  • 서버 지원 부족: 파이프라이닝은 HTTP/1.1에서 지원되지만, 모든 서버나 프록시가 이를 완벽하게 지원하지 않으며, 클라이언트 측에서도 제한적으로 사용된다. HOL 블로킹 문제나 서버 호환성 문제로 인해 파이프라이닝의 실질적인 사용지 제한되었다.
• 파이프라이닝 vs 멀티플렉싱

HTTP/2 는 파이프라이닝의 문제를 해결하기 위해 등장한 프로토콜입니다. HTTP/2에서는 멀티플렉싱 기법을 도입하여, 여러 요청과 응답을 동시에 처리할 수 있다. 멀티플렉싱은 파이프라이닝과 달리 요청과 응답을 병렬로 처리하기 때문에, 특정 요청의 지연이 다른 요청에 영향을 주지 않는다.따라서 HOL 블로킹이 발생하지 않는다.

HTTP/1.1, HTTP/2, HTTP/3 각각의 특징

• HTTP/1.1
  • 텍스트 기반 프로토콜
  • keep-alive 로 연결 재사용
  • 파이프라이닝 지원하지만 Head-of-Line-Blocking, 호환성 문제로 실질적 활용 적음
  • 브라우저는 병렬성을 위해 TCP 연결 여러 개 사용
• HTTP/2
  • 바이너리 프레이밍 기반
    • 바이너리 프레임 단위로 쪼개서 전송
  • 멀티플렉싱
  • 하나의 TCP 연결에서 여러 스트림 동시 처리
  • TCP 기반이라 전송 계층 HOL Blocking 존재
• HTTP/3
  • TCP 대신 QUIC(UDP 기반) 사용
  • 이미 브라우저/대형 서비스에서 점진적으로 채택 중
  • 스트림 단위 손실 처리로 전송 계층 HoL Blocking 완화

HTTPS

HTTPS

HTTPS는 HTTP에 TLS라는 암호화 계층을 덧씌운 것이다. https:// 와 기본 포트 443을 사용한다.

 

 

 

• HTTP는 평문으로 메시지를 교환하기 때문에 도청이 가능하다.
• HTTP를 사용하면서 통신 보안이 필요하다면 HTTPS를 사용하면 된다.
• HTTPS는 HTTP의 보안 버전으로 TLS 위에서 동작하는 HTTP다.
• HTTPS를 통해 전송되는 모든 HTTP 메시지는 SSL 계층을 거쳐 암호화, 복호화 된다.

SSL/TLS

• SSL(Secure Sockets Layer)은 컴퓨터 네트워크에 통신 보안을 제공하는 프로토콜이다.
• TLS(Transport Layer Security)라는 이름은 SSL이 표준화 되면서 바뀐 이름이다.
• SSL은 클라이언트가 서버와 주고 받는 통신 데이터에 대한 도청, 간섭, 위조를 방지해준다.
• 또한 데이터를 암호화 해주기 때문에 클라이언트 서버가 안전한 통신을 할 수 있게 해준다.

대칭키 암호화 방식(symmetric-key algorithm)

• 대칭키 암호화 기법에서는 암호화, 복호화할 때 사용되는 키가 같다.
• 같은 키를 사용하기 때문에 ‘대칭키’라고 부른다.
• 대칭키 암호화 기법에서 송신자와 수신자는 대칭키를 공유한다.
• 송신자는 대칭키를 사용해서 데이터를 암호화해서 전송하고
• 수신자는 수신한 데이터를 대칭키를 사용해서 복호화한다.

공개키 암호화(public key cryptosystem, 비대칭키 암호화)

• 공개키 암호화 기법에서는 암호화, 복호화할 때 사용되는 키가 다르다.
• 공개키는 모두에게 공개된 키
• 개인키는 개인이 비밀스럽게 갖고 있는 키

편지함 비유

• 열쇠로 잠긴 편지함에
• 누구나 편지를 넣을 수 있다.
• 하지만 개인키를 가진 사람만이 편지함을 열 수 있다.

전자 서명

 

개인키로 데이터를 암호화하고 공개키로 복호화 하는 방식

1. 데이터를 복호화하는 키는 모두 공개하고 데이터를 암호화하는 키는 개인만 갖게 하는 방식
   1. 특정 개인이 자신을 인증하는 용도로 사용할 수 있다.
2. A라는 특정 개인은 어떤 데이터를 개인키로 암호화한다. 그리고 공개키는 모두에게 공개한다.
3. 공개키를 가진 누군가는 A로부터 받은 암호화 데이터를 공개키로 복호화 해본다.
   1. 만약 복호화 된다면, 그 데이터는 A로부터 보내진 것이다.(A가 데이터를 보낸 쪽 임이 확실)
   2. 데이터가 복호화되지 않는다면, 그 데이터는 A로부터 보내진 데이터가 아니다.
4. 공개키를 가진 누군가는 A로부터 받은 암호화된 데이터는 인증을 위한 서명으로 사용되는 것이다.

• 기능
  • 메시지를 작성한 저자가 누구인지 알려준다.
  • 전자 서명은 오직 저자의 개인키를 통해서만 접근할 수 있기 때문에 저자의 개인 ‘서명’처럼 동작한다.
  • 전자 서명은 메시지 위조를 방지한다.
  • 만약 누군가 송신중인 메시지를 수정했다면 메시지에 대한 체크섬은 전자서명(원본의 체크섬)과 다를 것이다.
  • 체크섬 또한 저자의 개인키로 암호화되어 있기 때문에 위조할 수 없다.

편지 봉투 비유

• 전자 서명은 인장으로 편지 봉투를 봉인하는 것에 비유할 수 있다.
• 인장으로 봉인된 편지는 누구나 인장을 뜯어서 열어볼 수 있다
• 하지만 인장 확인을 통해 인장을 소유한 발신자가 편지를 보냈음을 증명할 수 있다.

HTTPS 암호화 과정(SSL Handshake 동작 과정)

 

• SSL 통신 과정은 “SSL 핸드셰이크 → Session → Session 종료” 순으로 진행된다.
• HTTPS 통신 과정을 그림과 함께 차례대로 살펴보자.
• SSL 핸드셰이크

먼저 서버와 클라이언트는 어떤 암호화 알고리즘을 사용할지 결정한다.

결정이 됐으면, 암호화 알고리즘을 사용해서 대칭키를 만들고 서로 나누어 가진다.

• 1번: Client Hello

클라이언트는 서버에게 클라이언트 측에서 생성한 랜덤 데이터, 클라이언트가 사용 가능한 암호화 알고리즘 후보들을 전송한다.

만약 이전에 서버와 SSL 핸드셰이킹을 진행했다면, 기존의 세션을 재활용하기 위해 세션 키를 전송한다.

• 2번: Server Hello

클라이언트가 보낸 암호화 알고리즘 후보들 중 사용 가능한 알고리즘을 선택한다.

서버는 클라이언트에게 서버 측에서 생성한 랜덤 데이터, 선택한 암호화 알고리즘, 인증서를 발송한다.

• 3번: 인증서 검증 및 대칭키 생성

클라이언트는 서버로부터 받은 인증서(전자서명)가 CA에 의해 발급된 것인지 확인하기 위해 클라이언트 측에 저장된 CA의 공개키로 인증서를 검증한다.

검증이 성공했다면, 해당 서버가 CA로부터 인증 받았다는 것이 보장된다. 서버를 믿을 수 있게 됨

클라이언트는 클라이언트 측에서 생성한 랜덤 데이터와 서버 측에서 생성한 랜덤 데이터를 사용해서 pre master secret라는 대칭키를 만든다.

pre master secret는 클라이언트와 서버의 암호화 통신에 사용될 대칭키다.

• 4번: pre master secret를 서버에게 전송

클라이언트는 pre master secret을 안전하게 암호화해서 서버에게 전달해야 한다.

인증서에 들어있던 서버의 공개키로 암호화해서 전달하는 것.

• 5번: pre master secret 수신

서버는 자신의 개인키로 pre master secret을 복호화해서 얻어낸다.

• 6번: master secret 및 session key 생성

서버와 클라이언트는 일련의 과정을 거쳐서 pre master secret를 master secret으로 만들고 master secret으로 session key를 생성한다.

DNS

DNS란

• DNS는 호스트의 Domain Name을 IP주소로 바꿔주는 애플리케이션 계층 프로토콜이다.
• DNS는 DNS 서버들이 계층구조로 구현된 분산 데이터베이스다. DNS 전세계적으로 수많은 호스트에 의해 사용되므로 여러 개의 서로 나누어서 구현하는 것이 효율적이고 확장성을 높여준다.
• DNS는 UDP위에서 동작하고 포트번호는 53번이다.
• DNS는 하나의 도메인 네임에 여러개의 IP주소를 대응할 수 있다. 이렇게 함으로써 부하를 분산하는 효과를 줄 수 있다.

DNS 작동 방식(동작 과정)

1. 브라우저에 URI(www.naver.com/index.html 를 입력하고 엔터
2. 브라우저는 URI로부터 호스트 네임(www.naver.com)을 추출하고 DNS 클라이언트로 넘긴다.
3. DNS 클라이언트는 DNS 서버로 호스트 네임을 전달한다.
4. DNS 서버는 호스트 네임에 대한 IP주소를 DNS 클라이언트에게 응답한다.
5. 브라우저가 DNS로부터 IP주소를 받으면, 브라우저는 그 IP 주소와 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화한다.

DNS 질의 종류

• 재귀적 질의
  • 클라이언트가 DNS 서버에게 보내는 요청
  • 클라이언트는 서버에게 도메인 이름에 대한 IP주소를 알려달라고 요청. 리졸버는 최종 IP 주소를 찾을 때까지 다른 DNS 서버들과의 통신을 책임지고 수행하며, 클라이언트는 최종 IP만 받는다.
  • 사용 주체: 일반 사용자 컴퓨터(스텁 리졸버)가 로컬 DNS 서버(리졸버)에 요청할 때 사용
• 반복적 질의
  • DNS 리졸버가 다른 DNS 서버에게 보내는 요청
  • 요청을 받은 서버는 최종 IP 주소를 알고 있다면 알려주지만, 모른다면 다음단계의 DNS 서버 주소를 응답으로 돌려준다. 그러면 리졸버는 새로운 주소로 요청하는 과정을 반복. 즉, IP 주소를 찾아가는 과정을 리졸버 자신이 책임지고 반복하는 방식
  • 사용 주체: DNS 리졸버가 루트 서버, TLD 서버, 권한 있는 네임 서버와 통신할 때 사용

DNS 서버에게 IP주소를 요청할 때, 왜 UDP를 사용할까?

UDP는 빠르기 때문에 DNS에 활용된다. DNS의 목적은 단지 도메인 네임에 대한 IP주소를 얻는 것이다. 따라서 오버헤드가 적고 빠른 UDP에서 동작하는 것이 적합하다.

DNS 레코드란

도메인 이름을 IP 주소와 연결하는 데 사용되는 일련의 지침. 인터넷상의 ‘전화번호부’와 같아서, 사람이 기억하기 쉬운 도메인 이름을 컴퓨터가 통신에서 사용하는 IP로 변환하는 역할.

주요 레코드의 종류 및 기능

• A 레코드(Address Record): 도메인 이름 또는 호스트 이름을 IPv4주소에 매핑한다. 웹사이트 접속 시 가장 기본적으로 사용됨
• AAAA 레코드(IPv6 Address Record): A레코드와 동일한 역할을 하지만, IPv6 주소에 매핑
• CNAME 레코드(Canoncial Name Record): 하나의 도메인 이름을 다른 도메인 이름으로 연결한다. 예를 들어, blog.example.com을 example.com과 연결