1. HTTP
1-1. HTTP 프로토콜이 무엇인가요?
가이드: 웹에서 HTTP가 어떤 역할을 하는지 설명하기
HTTP 프로토콜(HyperText Transfer Protocol)은 텍스트 기반의 통신 규약으로 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 통신 프로토콜입니다.
웹에서 브라우저와 서버 간에 데이터를 주고받기 위한 방식으로 HTTP 프로토콜을 사용합니다.
HTTP 프로토콜은 클라이언트-서버 모델을 따르고, 애플리케이션 레벨의 프로토콜로(7 계층), 일반적으로 TCP/IP 통신 위에서 동작하며 기본 포트는 80번입니다.
클라이언트-서버 프로토콜(보통 웹브라우저)
수신자 측에 의해 요청이 초기화되는 프로토콜입니다. 하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 fetch해온 하위 문서들로 재구성됩니다.
TCP/IP
TCP/IP 프로토콜은 인터넷에서 데이터 통신을 위한 실제 표준 프로토콜입니다. 인터넷의 기반이 되는 프로토콜로 인터넷에서 데이터를 주고받는 모든 기기들이 사용하는 통신 규약입니다.
[컴퓨터 네트워크/스터디] 네트워크 레이어
1-2. HTTP의 요청/응답 모델에 대해 설명해 주세요.
가이드: 클라이언트 서버가 요청과 응답을 주고받는 흐름 설명하기
HTTP 프로토콜로 데이터를 주고받기 위해서는 클라이언트가 요청(Request)을 보내고 서버가 응답(Response)을 받아야 합니다.
요청은 일반적으로 HTTP 메서드, 헤더, 바디 등을 포함합니다. 그 다음 서버는 요청을 처리하고, 성공 또는 실패에 따라 상태 코드를 포함한 응답, 응답 정보를 담은 헤더, 데이터를 포함한 본문을 클라이언트로 보내게 됩니다.
브라우저를 열고 URL을 입력하는 순간부터 HTTP 요청이 시작됩니다. 브라우저는 URL을 파싱하고 HTTP 요청 메시지(패킷)를 만들어 웹 서버로 전송합니다. 이때, 라우팅은 도메인 이름이 아닌 IP 주소를 이용하므로 여기서 DNS가 작용합니다. 패킷이 웹 서버에 도착하면 패킷의 메시지를 복원 후 WAS에 넘기고, 해당하는 응답 데이터를 찾아 응답 패킷에 넣어 클라이언트에 보냅니다. 클라이언트 측이 응답을 수신하면 끝이 납니다.
WAS(Web Application Server)
정적 + 동적 페이지를 제공하기 위해 만들어진 애플리케이션 서버입니다.
1-3. HTTP 메서드 중 GET과 POST의 차이점은 뭔가요?
가이드: 각 메서드가 리소스를 어떻게 다루는지 설명하기
URL을 이용하면 서버에 특정 데이터를 요청할 수 있습니다. 요청하는 데이터에 특정 동작을 수행하고 싶을 때 HTTP 요청 메서드를 이용합니다.
HTTP의 GET 메서드는 서버에서 어떤 데이터를 가져와서 보여줄 때 사용합니다. 예를 들어 글의 내용에 대한 목록을 보여줄 때 사용합니다. GET은 요청을 전송할 때 URL 주소 끝에 파라미터로 포함되어 전송됩니다.(쿼리 스트링) 파라미터에 내용이 노출되기 때문에 민감한 데이터를 다룰 때는 GET 요청을 사용해서는 안됩니다.
GET 메서드는 브라우저의 캐시를 사용하므로, 이전에 요청한 내용과 동일한 요청이면 서버로부터 정보를 받아오지 않고, 캐시에서 정보를 가져와 처리합니다.
HTTP의 POST 메서드는 서버상의 데이터 값이나 상태를 바꾸기 위해서 사용합니다. 예를 들어 글의 내용을 저장하거나 수정할 때 사용합니다. 전송해야 될 데이터를 HTTP 메서드의 Body에 담아서 전송합니다. 그래서 GET 메서드와 다르게 데이터 길이에 대한 제한이 없고, URL에 정보가 노출되지 않아 보안적으로 안전한 방식으로 전송됩니다.
1-4. PUT과 PATCH의 차이점은 뭘까요?
가이드: 멱등성에 대해 설명해 보기
PUT은 리소스의 모든 것을 업데이트하는 메서드이고, PATCH는 리소스의 일부를 업데이트하는 메서드입니다.
PUT 메서드는 클라이언트가 서버로 리소스 전체를 전송하면, 서버는 해당 리소스를 요청 URI에 저장하거나 업데이트합니다. 만약 해당 엔티티가 없으면 새로운 엔티티를 생성합니다. 이 방식은 전송한 데이터가 요청 URI의 리소스와 정확히 일치하도록 보장하기 때문에 PUT은 멱등성을 보장합니다.
반면 PATCH 메서드는 클라이언트가 서버로 업데이트하려는 일부분만 전송하면, 서버는 해당 엔티티의 해당 부분을 업데이트합니다. 이 방식은 전체 리소스를 전송하지 않아도 된다는 점에서 PUT보다 효율적입니다. 그러나 리소스의 일부분만 업데이트하면서 리소스 전체의 일관성을 보장하기 위해서는 추가적인 로직이 필요하기 때문에 PATCH는 멱등성을 보장하지 않습니다.
멱등성
동일한 요청을 여러 번 수행하더라도 동일한 결과를 가져오는 경우
1-5. HTTP 메서드가 뭔가요? 알고 있는 메서드 몇가지 알려주세요.
가이드: 개발하며 직접 사용해본 메서드를 사례를 들어서 설명
HTTP 메서드는 클라이언트의 HTTP 요청에 대한 명세입니다. HTTP 메서드를 통해 서버는 어떤 액션을 취해야 하는지 알 수 있습니다.
예를 들어 GET은 서버에게 데이터를 요청하는 것, POST는 서버에게 데이터를 전송하는 것, PUT은 서버 데이터 전체 수정 요청하는 것을 의미합니다.
1-6. HTTP 상태 코드가 뭔가요? 알고 있는 상태 코드 몇 가지 알려주세요.
가이드: 개발하며 직접 사용해 본 상태코드를 사례를 들어서 설명
HTTP 상태코드는 서버에서 설정해 주는 응답 정보입니다. 요청이 성공했는지 실패했는지, 실패한 경우에는 그 이유가 무엇인지 등을 알려줍니다. 따라서 HTTP 상태 코드는 웹 개발에서 디버깅과 에러 해결에 중요한 역할을 합니다.
주요 상태 코드는 200번대부터 500번대까지 다양하게 있습니다. 투두 리스트를 구현할 때 직접 사용해 본 상태 코드로 설명드리도록 하겠습니다.
100번대 상태코드는 정보를 전달하기 위한 것입니다.
200번대 상태 코드는 대부분 성공을 의미합니다.
새로 고침 후 작성한 투두 리스트를 가져오는 GET 요청이 성공했을 때 상태코드 200을 사용해 봤습니다.
300번대 상태 코드는 대부분 클라이언트가 이전 주소로 데이터를 요청하여 서버에서 새 URL로 리다이렉트를 유도하는 경우입니다.
400번대 상태 코드는 대부분 클라이언트의 코드가 잘못된 경우입니다. 유효하지 않은 자원을 요청했거나 요청이나 권한이 잘못된 경우에 발생합니다.
Headers의 Authorization에 잘못된 localStorage의 값을 넘겨줬을 때 상태코드 401을 사용해 봤습니다.
500번대 상태 코드는 서버 쪽에서 오류가 난 경우입니다.
프로젝트를 진행할 때 백엔드를 담당하던 팀원이 서버를 잠시 내렸을 때 상태코드 503을 사용해 봤습니다. 서버가 과부하되거나 유지 보수로 인해 내려간 경우에 확인할 수 있습니다.
1-7. HTTP 헤더가 뭘까요? 알고 있는 헤더 몇 가지 설명해 주세요.
가이드: 개발하며 직접 사용해 본 헤더를 사례를 들어서 설명
HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담고 있습니다.
HTTP 헤더에는 General Header, Request Header, Response Header, Entity Header 이렇게 크게 4가지가 있습니다.
General Header는 공통 헤더로 요청과 응답 모두 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더입니다. 메시지 교환 후 TCP 연결을 유지하기 위한 Connection을 사용해 봤습니다.
Request Header는 패치될 리소스나 클라이언트 자체에 대한 정보를 포함하는 헤더입니다. 인증 토큰을 서버로 보낼 때 Authorization을 사용해 봤습니다.
Response Header는 위치 또는 서버 자체에 대한 정보(이름, 버전)와 같이 응답에 대한 부가적인 정보를 갖는 헤더입니다.
ex. Server(웹 서버 종류)
Entity Header는 엔티티 바디(콘텐츠, 본문, 리소스)에 대한 자세한 정보를 포함하는 헤더입니다. 응답하는 내용의 타입과 문자 포맷을 표현할 때 Content-Type을 사용해봤습니다.
# 조금 더 디테일한 질문
1-8. HTTP의 무상태성(Stateless)에 대해서 설명해주세요.
가이드: 무상태성으로 인해 생기는 HTTP의 장단점에 대해 설명
Stateless는 서버가 클라이언트의 정보를 유지하지 않는 특성입니다.
서버는 기본적으로 클라이언트에 대한 정보가 없기 때문에 클라이언트가 누군지 식별할 수 없습니다.
클라이언트를 식별하기 위해 쿠키, 세션과 같은 상태유지 기술을 사용할 수 있습니다.
1-9. HTTP Keep-Alive에 대해서 설명해주세요.
가이드: 성능과 관련하여 연관지여 설명
HTTP Keep-Alive는 HTTP 요청/응답시 TCP 연결을 유지하는 기능입니다.
이를 통해 매번 연결을 하지 않아도 여러 개의 요청과 응답을 처리할 수 있기 때문에 웹 응답 속도를 빠르게할 수 있습니다.
1-10. HTTP 파이프라이닝에 대해서 설명해주세요.
가이드: 성능과 관련하여 연관지여 설명
요청에 대한 응답을 받기 기다리지 않고 여러개의 요청을 보내는 것입니다.
응답을 기다리지 않기 때문에 서버와 클라이언트간의 대기 시간을 줄일 수 있습니다.
조금 더 디테일 한 설명
파이프라인 프로토콜은 인터넷 프로토콜 스위트(IP Suite)에서 사용되는 프로토콜 중 하나입니다. 이 프로토콜은 여러 개의 네트워크 연결을 통해 데이터를 전송하는 기술로, 병렬 처리를 위한 기법 중 하나입니다.
파이프라인 프로토콜을 사용하면 여러 개의 요청과 응답이 동시에 처리될 수 있어서, 전체적인 처리 시간을 단축할 수 있습니다. 파이프라인 프로토콜은 여러 개의 연결을 동시에 사용하면서, 각 연결에서 전송된 데이터를 순서대로 처리합니다.
예를 들어, 웹 브라우저에서 HTML 페이지를 요청하면, 해당 페이지의 내용과 함께 이미지와 스크립트 등의 추가적인 자원들도 함께 요청됩니다. 이때 파이프라인 프로토콜을 사용하면, 여러 개의 요청과 응답이 동시에 처리될 수 있어서, 모든 자원을 받아오는 시간을 단축할 수 있습니다.
파이프라인 프로토콜은 HTTP/1.1부터 사용되기 시작했습니다. 파이프라인 프로토콜를 통해 웹 페이지 로딩 시간을 단축하고, 사용자 경험을 향상시키는 데에 큰 도움이 됩니다.
1-11. HTTP/1.1, HTTP/2, HTTP/3 각각의 특징에 대해 설명해주세요.
가이드: 각 버전의 핵심 특징 1가지씩만 들어서 설명
1.1 버전에서는 keep-alive 헤더를 통해 하나의 TCP 연결로 여러 요청을 보낼 수 있는 특징이 있습니다.
2 버전에서는 Multiplexed Streams라는 특징이 있는데 TCP 연결에 동시에 여러 요청을 보낼 수 있는 특징이 있습니다. 이는 keep-alive보다 더 효율적인 방식입니다.
3 버전에서는 UDP 기반 QUIC 프로토콜을 사용합니다. 속도가 빠르면서도 신뢰적인 데이터 전송을 보장해줍니다.
1-12. HTTP에서 캐싱을 구현하는 방법에는 어떤 것들이 있나요?
가이드: 캐싱 관련 HTTP 헤더에 대해서 설명
Cache-Control, Last-Modified & If-Modified-Since 헤더를 통해 캐싱을 구현할 수 있습니다.
Cache-Control를 통해서는 서버의 응답 데이터를 브라우저에 특정 기간 동안 캐싱하게 할 수 있습니다.
서버는 응답 헤더 Last-Modified에 데이터 수정 날짜를 보냅니다. 클라이언트는 If-Modified-Since헤더에 Last-Modified 값을 넣어서 서버에 요청을 보내는데, 서버는 이 값들을 비교해서 데이터가 수정되지 않았다면 304 코드를 응답해서 클라이언트가 캐시된 데이터를 사용하게 합니다.
2. HTTPS
2-1. HTTPS에 대해서 설명해 주세요.
가이드: 보안 관점에서 HTTP와 차이점 설명
HTTPS(Hypertext Transfer Protocol Secure)는 HTTP와 동일한 방식으로 작동하지만, HTTP 프로토콜의 암호화된 버전입니다.
SSL(Secure Socket Layer) 인증서를 사용하고, 일반 HTTP 요청 및 응답을 암호화하여 클라이언트가 민감한 정보를 서버와 안전하게 주고받을 수 있도록 도와줍니다.
2-2. SSL/TLS이 뭔가요?
가이드: 개념 설명
SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 인터넷에서 정보를 안전하게 전송하기 위한 프로토콜입니다. 클라이언트와 서버 간에 상호 인증을 하고, 키 교환을 통해 공개키 암호화 방식을 사용하여 데이터를 암호화하고 복호화합니다.
SSL/TLS를 사용하는 웹 사이트는 HTTPS를 사용하여 웹 사이트를 안전하게 제공합니다. SSL은 오래전에 개발되었으며, TLS는 SSL이 표준화 되면서 바뀐 이름입니다. 현재 대부분의 웹 브라우저와 웹 서버는 TLS를 사용합니다.
SSL/TLS는 인터넷 뱅킹, 온라인 쇼핑 등에서 사용되며, 인터넷 보안의 핵심 요소 중 하나입니다.
# 조금 더 디테일한 질문
2-3. HTTPS 암호화 과정에 대해 설명해주세요.(SSL 핸드셰이크에 대해 설명해주세요.)
가이드: 암호화 흐름에 대해 순차적으로 설명(암호화 방식에 대해 설명)
1. 웹 서버(사이트)는 서버 정보와 서버의 공개키를 인증 기관에 주면서 인증 요청을 합니다.
2. 인증 기관은 서버로 부터 받은 서버 정보와 공개키를 인증기관의 개인키로 암호화하여 인증서를 만듭니다.
3. 인증 기관은 인증서에 대한 공개키를 브라우저들에게 제공하고, 서버에 인증서를 발급합니다.
4. 클라이언트가 웹 서버에 접속하면, 먼저 서버로부터 인증서를 받습니다.
5. 클라이언트는 인증 기관으로부터 받은 공개키를 사용해 인증서를 검증합니다.
6. 신뢰 할만한 인증기관이라면, 대칭키를 만들고, 인증서에 들어있던 서버의 공개키를 사용해 대칭키를 암호화하여 서버에 전송합니다.
7. 서버는 안전하게 클라이언트가 만든 대칭키를 받습니다.
8. 이제 클라이언트와 서버는 안전하게 공유된 대칭키를 통해 암호화 통신이 가능해집니다.
3. DNS
3-1. DNS가 뭔가요?
가이드: 인터넷에서 DNS가 어떻게 활용되는지 설명
DNS(Domain Name System)는 도메인 이름을 IP 주소로 변환해주는 프로토콜이자 계층형 구조로 구현된 분산 데이터베이스입니다. 인터넷에서 컴퓨터가 통신할 때 IP 주소를 사용하여 패킷을 주고받습니다. 하지만 IP 주소는 아무 의미 없는 숫자로 구성되기 때문에 사람이 IP 주소를 기억하고 입력하는 것은 불편하므로, 도메인 이름을 사용합니다.
호스트가 도메인 네임에 대한 IP 주소를 요청하면 DNS는 계층 질의를 통해 IP 주소를 얻어다가 줍니다. 만약 로컬 DNS에 해당 IP 주소가 캐싱되어 있다면 바로 받습니다.
3-2. DNS 작동 방식에 대해 설명해 주세요.
가이드: 도메인 네임에 해당하는 IP주소를 어떻게 가져오는지 과정을 설명
DNS 서버에는 도메인 주소와 IP 주소의 쌍이 저장됩니다.
브라우저에서 도메인 이름을 입력하면 로컬 DNS 캐시에서 IP 주소를 찾습니다. 로컬 캐시에 대한 정보가 없으면 먼저 루트 DNS 서버를 찾습니다. 루트 DNS 서버는 해당 도메인 이름의 최상위 도메인 서버의 IP 주소를 제공하며, 클라이언트는 이를 찾아가며 그다음 수중의 DNS 서버로 이동하여 IP 주소를 찾습니다. 최종적으로 해당 IP 주소를 로컬 DNS 캐시에 저장하여 이후에 더 빠른 검색을 가능하게 합니다.
# 조금 더 디테일한 질문
3-3. DNS 질의 종류에 대해 설명해주세요.
가이드: 재귀적 질의, 반복적 질의에 대해 설명
재귀적 질의는 도메인 네임에 해당하는 IP주소를 통해 DNS가 다른 DNS에게 재귀적으로 IP 주소를 물어보는 것을 뜻합니다.
반복적 질의는 IP 주소를 찾기 위해 반복적으로 질의하는 것입니다.
로컬 DNS가 루트 DNS에게 IP주소를 물어봤는데 없으면 TLD DNS에게 물어보고 또 없으면 authoriative DNS에 반복적으로 물어보는 것을 예시로 들 수 있습니다.
마무리
궁금한 점
StackOverFlow의 멱등성 예제가 명확하게 이해되지는 않습니다. 제가 이해한 방향성이 맞을까요?
참고자료
- MDN, HTTP
- git blog, HTTP 프로토콜
- tistory, GET vs PUT
- velog, PUT vs PATCH
- StackOverFlow, 멱등성
- velog, HTTP 헤더
- MDN, HTTP 헤더
- HTTPS와 HTTP
- aws, SSL/TLS
질문이나 잘못된 점은 댓글로 남겨주세요 :)💖
'CS > [JSCODE] 컴퓨터 네트워크' 카테고리의 다른 글
| [컴퓨터 네트워크/스터디] IP Address (0) | 2023.05.07 |
|---|---|
| [컴퓨터 네트워크/스터디] IP Address (0) | 2023.05.01 |
| [컴퓨터 네트워크/스터디] TCP (0) | 2023.04.24 |
| [컴퓨터 네트워크/스터디] UDP, 신뢰적 데이터 전송의 원리 (2) | 2023.04.21 |
| [컴퓨터 네트워크/스터디] 네트워크 레이어 (0) | 2023.04.13 |
댓글