네트워크 스터디 2주차

HTTP 프로토콜이란?

트랜스포트 계층(ex, tcp 혹은 udp) 위에서 동작하는 어플리케이션 계층 프로토콜 중에 하나입니다.

브라우저 같은 어플리케이션에서 html 문서와 같은 리소스를 교환할 수 있게 하는 통신규약을 말합니다.

또한 클라인트-서버 아키텍처를 가지고 있어서 통신을 위해서 request 메세지를 요청하고자 하는 서버에 요청을 해야하고 해당 응답으로 response 메세지를 받게 되어있습니다

 

HTTP의 요청/응답 모델이란?

어플리케이션 계층은 요청/응답 모델을 가질 수도 있고 피어투피어 모델을 가질 수도 있다.

http는 요청/응답 모델을 가진 것이며 개별적인 요청 메세지에 대한 응답 메세지를 주고 받는 모델이다.

요청 메세지는 메서드, URI, 프로토콜 버전, 헤더, 바디를

응답은 프로토콜 버전, 상태코드, 상태코드 설명, 헤더, 바디로 구성되어있습니다.

 

HTTP 메서드 중 GET/POST의 차이점

* GET : 특정한 리소스를 가져오도록 요청합 - 멱등성 o

* POST: 서버로 데이터를 전송 (서버의 변경 사항을 생성) - 멱등성 x

 

HTTP 메서드 중 PUT/PATCH의 차이점

* PUT : 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체 - 멱등성 o

* PATCH: 리소스의 부분적인 수정을 일으킴 - 멱등성 ▲ 

쓰기 나름. 동일한 요청이 다른 결과를 일으킬 수 있다. (ex - 페이지 조회 횟수 +1 하는 api)

 

HTTP 상태코드

1xx 요청이 끝나지 않음 (100번대는 잘 사용하지 않음)

2xx 정상 - 200 

3xx redirection - 301 server, 304, 307

4xx client error - 401, 404

5xx  server error - 500 . 503 server unavailable

 

HTTP 헤더란? 

리퀘스트나 리스폰스에 부가적인 정보를 헤더에 넣어 전송한다.

ex) 캐싱 (age, cache-control : no-cache), cors 정보, 유저 에이전트, X-Forwarded-For 와 같은 프록시 관련 정보

 

HTTP 무상태성(stateless)

http는 요청들 간의 연관성을 알지 못하기 때문에 모든 요청을 개별적으로 처리하게 된다.

그러나 같은 사용자가 보낸 요청들이라는 것을 알아야할 필요하는 어플리케이션에서는 http 쿠키를 이용해서 상태가 있는 세션을 만들어서 처리할 수 있다.

 

HTTP Keep-Alive

HTTP/1.0에서 사용되던 헤더로 단기 커넥션, 그러니까 통신 할 때마다 tcp 커넥션을 맺고 핸드쉐이크 과정을 거쳐 요청이 처리되게 되는데 이때 성능 저하가 생기게 되었고 이를 극복하기 위해 요청 시마다가 아닌 얼마간의 커넥션을 열어놓는 옵션을 두게 되었다. (재활용을 하게 되는 것이다)

그리고 얼마간 열어놓을지를 Keep-Alive 헤더에 넣어서 보낸다.

 

HTTP 파이프라이닝

HTTP/1.1에서는 기본적으로 단기 커넥션이 아니라 지속 커넥션을 지원하기 시작했다. 요청을 보내고 기다리는 게 아니라 요청을 연속적으로 보낼 수 있게 되었다.

하지만 http 메세지는 기본적으로 요청에 대한 응답은 순서대로 와야하기 때문에, 먼저 끝난 작업도 기다리게 되면서 이 때 데이터 레이턴시가 발생하게 된다. - HEAD OF LINE BLOCKING 

이러한 단점으로 현재는 거의 사용하지 않는 기술이다.

그외) 응답 실패시? 

 

HTTP/1.1 , HTTP/2, HTTP/3

잘 모름

 

HTTPS란?

http 프로토콜이 확장된 것으로 TLS를 사용하여 암호화된 데이터로 커넥션을 맺는 프로토콜을 말한다.

TLS는 transport layer security의 준말로 해커가 해당 통신을 내용을 해킹해도 안전하다.

 

SSL/TLS이 뭔가요?

데이터를 통신할 때에 여러 네트워크를 거치면서 개인 정보 등 중요 정보의 해킹의 우려가 있다. 

따라서 tls와 ssl은 데이터를 통신할 때 데이터를 암호화하여 통신하게 되고 이걸 사용하는 모든 웹사이트는

브라우저에 자물쇠 아이콘이 표시된다.

tls는 ssl의 후속버전으로 ssl은 deprecated 버전, tls 1.1, 1.2는 보안에 취약한 버전으로 현재는 1.3이 안정적인 버전으로 알려져있다.

-ssl과 tlssms 키 교환에 사용되는 알고리즘 등에 차이가 있다.

ssl - secure socket layer

tls - transpor layer security (ssl의 단점을 보완한 보점)

 

HTTPS 암호화 과정(SSL Handshake의 동작 과정 - tls도 동일한 구조를 가짐.)

1. TCP handshake - tcp 연결을 맺는다. (http 통신과 다를 바 없음)

2. 인증서 확인 과정

클라이언트(브라우저)가 서버에게 "hello" 메세지를 보낸다.

이 메세지는 TLS 버전, 사이버 스위트 (암호화에 사용될 알고리즘)가 포함된다.

3. 해당 정보를 바탕으로 서버는 클라이언트에게 응답을 보내고 인증서를 보내게 된다.

-> 둘 간의 tls 버전과 사이버 스위트를 맞추게 되는 것이다.

이때 인증서에는 서버가 발급한 퍼블릭키가 포함되는데 이는 비대칭 암호화에 사용된다.

4. 키 교환 - 클라이언트의 키 교환, 사이퍼 스펙 변경, 종료, 사이퍼스펙 변경, 종료

rsa 키로 예를 들면

클라이언트가 퍼블릭 키로  RSA로 암호화된 세션키를 생성하고 그것을 서버에게 전달한다.

그러면 서버는 암호화된 세션 키를 서버가 가지고 있는 프라이빗 키로 해독한다.

이제 클라이언트와 서버 모두 동일한 세션키를 가지고 있게 된다.

5. 데이터 전달. 둘다 세션키를 가지고 데이터를 암호화한 데이터를 주고 받을 수 있게 된다.

 

대칭키 암호화 방식/ 비대칭키 암호화 방식

앞서 본 ssl 핸드쉐이크 방식을 살펴보면 비대치킹 암호화 방식으로 시작했다가 종전에 대칭키 암호화 방식으로

데이터 전송을 하는 것을 확인해볼 수 있었다. 

클라이언트와 서버가 서로 다른 암호화 키를 사용했다가 이후에 같은 키를 공유하게 되는 것이다.

종전에 비대칭 암호화 방식을 사용하는 이유는 비대칭 암호화 방식은 계산을 많이 필요로 하기 때문이다.

반대로 대칭 암호화 방식은 그렇지 않기 때문에 대량의 데이터 전송에는 대칭 암호화 방식이 적절하다. 

 

DNS

도메인 네임 서버로, 문자열로 된 URL(URI)로 통신을 원하는 컴퓨터의 IP를 얻을 수 있는 주소록 같은 서버를 말한다.

 

DNS의 작동방식 / 질의 종류

dns는 dns 클라이언트와 서버 사이에 질의(쿼리)를 보내게 된다.

dns에게 물어보기 전에 컴퓨터는 host 파일을 가장 먼저 확인하고 이후 dns 캐시 서버, 그다음에는 ISP의 로컬 DNS를 확인한다.

만약 해당 과정에서 찾을 수 없으면 

계층적 구조를 가진 DNS의 가장 최상단 루트에 있는 13개의 서버에게 요청을 하게 된다.

예를 들어 www.naver.com이 있으면 루트 서버에서 *.com에 대한 dns 목록을,

*.com에서는 naver 서버에 대한 dns 목록을, 

최종적으로는 naver서버에서 www에 대한 dns 목록을 반환하여 준다. 

이렇게 반복적으로 DNS가 다른 DNS에게 쿼리를 보내 응답을 요청하는 질의를 반복 (iterative) 질의라고 하고, 

해당 요청에 대한 응답을 주는 쿼리를 재귀(recursive) 질의라고 한다.