🎯 1. HTTP
HTTP 프로토콜이 무엇인가요? (가이드 : 웹에서 HTTP가 어떤 역할을 하는지 설명하기 )
HTTP는 HyperText Transfer Protocol의 약자로, hyperText를 전송하기 위한 통신 규약입니다.
HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초가 됩니다.
HTTP의 요청/응답 모델에 대해 설명해주세요. (가이드 : 클라이언트 서버가 요청과 응답을 주고 받는 흐름 설명하기)
1. TCP 연결 : TCP 연결은 (단일 또는 여러 개의) 요청을 보내거나 응답을 받는 데 사용됩니다. 클라이언트는 새 연결을 열거나, 기존 연결을 재사용하거나, 서버로 가는 여러 개의 TCP 연결을 열 수 있습니다.
2. HTTP 메시지를 전송(요청)합니다.
3. 요청에 맞게 서버가 보내준 응답을 읽습니다.
4. 연결을 닫거나 다른 요청을 위해 연결을 재사용합니다.
HTTP 메서드중 GET과 POST의 차이점은 뭔가요? (가이드 : 각 메서드가 리소스를 어떻게 다루는지 설명하기)
- get과 post 의 차이점은 첫번째로 사용목적입니다. get은 서버에 데이터를 요청할 때, post는 서버의 데이터를 새로 생성하거나 업데이트 할 때 사용합니다.
- 두번째는 요청 body의 유무입니다. get은 url 파라미터에 요청하는 데이터를 담아 보내기 때문에 body가 없지만 post는 body에 데이터를 담아 보내기 때문에 body가 존재합니다.
- 세번째로는 멱등성입니다. get요청은 멱등이며 post는 멱등이 아닙니다. (여기서 멱등성이란 서버의 결과가 달라지지 않는 성질을 의미합니다.)
PUT과 PATCH의 차이점은 뭘까요? (가이드 : 멱등성에 대해 설명해보기 )
PUT은 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 덮어씁니다. PATCH는 리소스의 부분적인 수정을 할 때 사용됩니다. PATCH와 PUT의 차이는 멱등성의 유무인데, 멱등성이란 어떤 대상에 같은 연산을 여러번 적용해도 서버의 결과가 달라지지 않는 성질입니다.
PUT은 요청에 대하여 리소스를 통째로 바꿔버리기 때문에 요청을 한번하든 여러번하든 결국 서버의 상태는 같아지므로 PUT은 멱등성을 가지지만, PATCH는 리소스 일부에 대하여 변화를 명령할 수 있기 때문에 단일 호출과 다중 호출에 대한 서버의 상태가 다를 수 있어 이 경우 멱등하지 않습니다.
결과적으로 PUT 메소드는 반드시 멱등성을 보장하지만 PATCH 메소드는 멱등성을 보장하지 않을 수도 있습니다.
HTTP 상태 코드가 뭔가요? 알고 있는 상태 코드 몇가지 알려주세요. ( 가이드 : 개발하며 직접 사용해본 상태코드를 사례를 들어서 설명 )
1. 상태코드 200은 요청한 통신이 성공적으로 수신되었을 때 나타나는 상태입니다.
2. 상태코드 400은 200과 반대로 클라이언트(요청) 오류로 요청한 통신에 실패하였을 때 나타나는 코드입니다.
(대표적으로 404 : 서버가 요청받은 리소스를 찾지 못함, 403 : 클라이언트가 콘텐츠에 접근할 권리 없음, 401 : 인증되지 않음,
409 : 서버와 클라이언트의 요청이 충돌)
3. 상태코드 300은 리다이렉션 메시지로 요청에 대해 하나 이상의 응답이 가능한 경우의 상태코드입니다.
4. 상태코드 500은 서버오류로 인한 통신실패입니다.
HTTP 헤더가 뭘까요? 알고 있는 헤더 몇 가지 설명해주세요. ( 가이드 : 개발하며 직접 사용해본 헤더를 사례를 들어서 설명 )
헤더는 크게 4가지 항목으로 분류할 수 있습니다.
- General Header(공통 헤더) : 최종적으로 전송되는 데이터와는 관련이 없는 헤더
ex) Date(현재시간), Via(중계 프록시 서버의 이름), Connection(네트워크 접속 유지할지 말지)
- Request Header(요청 헤더) : 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
ex) Host(요청하려는 서버 호스트 이름과 포트번호), If-Modified-Since(여기에 쓰여진 시간 이후로 변경된 리소스 취득)
- Response Header(응답 헤더) : 응답에 대한 부가적인 정보를 갖는 헤더
ex) Server : 웹서버의 종류, Set-Cookie : 서버측에서 클라이언트에게 세션 쿠키 정보를 설정
- Entity Header(엔티티 헤더) : 바디에 대한 자세한 정보를 포함하는 헤더
ex) Content-type : 리소스의 media type 명시 (application/json, text/html)
HTTP의 무상태성(Stateless)에 대해서 설명해주세요. (가이드 : 무상태성으로 인해 생기는 HTTP의 장단점에 대해 설명)
Stateless 란 비용을 줄이기 위해 서버가 클라이언트의 상태를 가지고 있지 않는 것입니다.
Stateless 방식은 요청을 할 때 모든 정보를 각 서버에게 전달해야 하기 때문에 요청이 복잡해지고 비효율적인 단점이 있는 반면에 무상태는 서버를 쉽게 바꿀 수 있어 확장성에 용이하며 서버가 클라이언트 상태를 가지고 있지 않기 때문에 서버 비용을 줄일 수 있는 장점이 있습니다.
HTTP Keep-Alive에 대해서 설명해주세요. ( 가이드 : 성능과 관련하여 연관지여 설명 )
keep-alive란 persistent connection, 지속연결을 맺는 기법 중 하나로 지속연결이 되어 있지 않으면 연속적으로 여러 요청을 보낼 때마다 계속해서 연결을 맺었다 끊었다 해야 하는 부하가 생기는데 keep-alive를 활용하면 지속연결을 유지할 수 있어 불필요한 연결의 맺고끊음을 최소화해 네트워크 부하를 줄일 수 있습니다.
HTTP 파이프라이닝에 대해서 설명해주세요. ( 가이드 : 성능과 관련하여 연관지여 설명 )
파이프라이닝이란 클라이언트와 서버간 요청과 응답의 효율성을 개선하기 위해 만들어진 개념으로 파이프라이닝을 통해
요청들에 대한 응답을 미뤄 하나의 connection으로 다수의 요청과 응답을 처리하여 네트워크 부하를 줄일 수 있습니다.
HTTP/1.1, HTTP/2, HTTP/3 각각의 특징에 대해 설명해주세요. ( 가이드 : 각 버전의 핵심 특징 1가지씩만 들어서 설명 )
HTTP/1.1
- Connection Keep-Alive (기존 연결에 대해서 handshake 생략가능) 개념 추가
- 파이프라이닝 추가
HTTP/2
- 완전히 새로운 프로토콜이 아닌 개선사항을 적용해 수정된 성능향상에 초점을 맞췄습니다.
(HTTP/1.1의 Connection Keep-Alive, Pipelining의 개선)
HTTP/3
- 기존의 HTTP들과는 다르게 UDP 기반의 프로토콜인 QUIC 을 사용하여 통신하는 프로토콜
- TCP가 아닌 UDP 기반의 통신을 한다는 것
- Tcp 연결에 비해 1 round trip time만 소요됨 -> 지연시간 단축
HTTP에서 캐싱을 구현하는 방법에는 어떤 것들이 있나요? ( 가이드 : 캐싱 관련 HTTP 헤더에 대해서 설명 )
먼저 http에서 캐싱은 불필요한 네트워크 요청을 피하기 위해 주어진 리소스의 복사본을 저장하고 있다가 요청 시에 그것을 제공하는 기술입니다.(저장하는 곳이 캐시)
--> 여기까지 설명하고 기억이 구현방법에 대해 기억이 나지 않으면 자세한 구현방법은 학습이 필요할 것 같다고 답변하기
1. 브라우저는 서버에 index.html 파일을 요청합니다.
2. 서버는 index.html파일을 찾아보고 존재 하는 파일이라면 파일 내용을 브라우저에게 몇 가지 header값과 함께 응답합니다.
3. 브라우저는 응답 받은 내용을 브라우저에 표시하고 응답 헤더의 내용에 따라 캐쉬 정책을 수행합니다.
(응답 헤더에 Last-Modified, Etag, Expires, Cache-Control:max-age 항목이 존재 한다면 복사본을 생성하고 값을 저장 )
캐싱 동작은 요청헤더와 응답헤더의 조합에 의해 이루어지는데, If-None-Match 및 If-Modified-Since는 새로 고침 검사에 영향을 미칩니다. 또한 응답헤더인 Cache-Control은 캐싱 메커니즘을 지정하기 위해 사용되고 ETag와 Last-Modified 헤더는 ETag와 리소스가 변경되었는지 여부를 확인합니다.
🎯 2. HTTPS
HTTPS에 대해서 설명해주세요. ( 가이드 : 보안 관점에서 HTTP와 차이점 설명 )
HTTP = HTTP + SSL/TLS
HTTPS(https://)는 SSL(Secure Socket Layer) 인증서를 사용하는 HTTP(http://)이며, 표준 HTTP와 동일한 방식으로 작동합니다. SSL(또는 TLS) 인증서는 일반 HTTP 요청 및 응답을 암호화합니다. 따라서 HTTPS는 HTTP보다 더 안전한 보안용 프로토콜이라고 할 수 있습니다.
HTTP와 HTTPS의 유일한 차이점은 HTTPS를 사용한 웹 페이지를 통해 전송되는 모든 데이터는 추가적인 보안 계층이 있습니다. 이를 TLS(전송 계층 보안) 프로토콜이라고 합니다. 서버와 주고받는 데이터가 암호화되기 때문에 웹사이트에 추가적인 보호를 제공합니다. 즉, 개인 데이터를 훔치거나, 해킹하거나 볼 수 없도록 작동합니다.
SSL/TLS이 뭔가요? ( 가이드 : 개념 설명 )
SSL은 암호화 기반 인터넷 보안 프로토콜로 전달되는 모든 데이터를 암호화하고 특정한 유형의 사이버 공격도 차단합니다. TLS은 최신 암호화 프로토콜로 SSL의 업데이트 버전입니다. ssl과 tls은 http 와 tcp 계층 사이에 위치해있습니다.
HTTPS 암호화 과정에 대해 설명해주세요. (SSL 핸드셰이크에 대해 설명해주세요.) (가이드 : 암호화 흐름에 대해 순차적으로 설명(암호화 방식에 대해 설명)
여기서 https의 SSL은 바로 "공개키 암호화 방식"을 이용해서 문서를 암호화합니다.
이 방식의 핵심은 바로 공개키와 개인키가 있는 것인데, 공개키는 누구에게나 공개되어 "모두가 접근이 가능한 키"고 개인키는 딱 한 사람만이 소유해 "본인을 제외한 누구도 접근이 불가능한 키"입니다.
공개키로 데이터를 암호화 하고 개인키로 복호화하여 데이터를 사용합니다.
1. 서버는 공개키와 개인키를 만든다.
2. 믿을만한 저장소(CA)와 계약해 두 키를 관리하도록 한다.
3. CA도 자신만의 공개키와 개인키를 가지고 자체 암호화를 하여 SSL 인증서를 발급한다.
4. 클라이언트의 데이터 요청이 들어오면 서버는 CA에서 만든 SSL 인증서를 보내준다.
5. 클라이언트는 CA의 공개키를 이용해 SSL 인증서를 복호화(암호 해독)한다.
6. SSL 내부의 서버 공개키를 이용해서 암호화해서 인증서를 서버에게 보낸다.
7. 서버는 개인키로 암호화된 인증서를 복호화(암호 해독)하고 다시 암호화 하여 클라이언트에게 보낸다.
이 같은 방식으로 서버와 클라이언트의 문서를 외부에 노출되지 않도록 합니다.
🎯 3. DNS
DNS가 뭔가요? (가이드 : 인터넷에서 DNS가 어떻게 활용되는지 설명)
웹사이트에 접속 할 때 우리는 외우기 어려운 IP 주소 대신 도메인 이름을 사용합니다. 도메인 이름을 사용했을 때 입력한 도메인을 실제 네트워크상에서 사용하는 IP 주소로 바꾸고 해당 IP 주소로 접속하는 과정이 필요합니다.이러한 과정, 전체 시스템을 DNS(도메인 네임 시스템)라고 합니다.
DNS 작동 방식에 대해 설명해주세요. (가이드 : 도메인 네임에 해당하는 IP주소를 어떻게 가져오는지 과정을 설명)
1. 웹 브라우저에 www.naver.com을 입력하면 먼저 Local DNS에게 "www.naver.com"이라는 hostname"에 대한 IP 주소를 질의하여 Local DNS에 없으면 다른 DNS name 서버 정보를 받음(Root DNS(적절한 최상위 도메인에 대해 권한이 있는 네임 서버 목록을 반환함으로써 다른 요청에 응답) 정보 전달 받음)
2. Root DNS 서버에 "www.naver.com" 질의
3. Root DNS 서버로 부터 "com 도메인"을 관리하는 TLD (Top-Level Domain)(.com을 관리하는 서버) 이름 서버 정보 전달 받음
4.TLD에 "www.naver.com" 질의
5.TLD에서 "name.com" 관리하는 DNS 정보 전달
6."naver.com" 도메인을 관리하는 DNS 서버에 "www.naver.com" 호스트네임에 대한 IP 주소 질의
7.Local DNS 서버에게 www.naver.com에 대한 IP 주소 222.122.195.6 응답
8.Local DNS는 www.naver.com에 대한 IP 주소를 캐싱을 하고 브라우저에게 IP 주소 정보 전달
DNS 질의 종류에 대해 설명해주세요. (가이드 : 재귀적 질의, 반복적 질의에 대해 설명)
- 재귀적 질의
사용자가 Local DNS 서버에 query를 보내면 Local DNS server가 Root name 서버에 query를 보내고, Root 서버는 자신의 서버에 없으면 해당 TLD 서버에 요청합니다. 이렇게 재귀적으로 실제 도메인 정보를 가지고 있는 서버까지 query가 이동하여 IP 주소를 얻는 방법입니다. 재귀적인 방법은 Root 서버에 너무 큰 부담을 준다는 단점이 있습니다.
- 반복적 질의
사용자가 Local DNS 서버에 query를 보내면 Local DNS 서버가 Root name 서버에 query를 보내 TLD 서버의 주소를 반환받고, 다시 TLD 서버에 query를 보냅니다. 이렇게 최종 IP 주소를 받을 때까지 요청과 응답을 계속해서 Local DNS 서버가 반복하는 방법입니다.
🕹️ 어려웠던 점 / 느낀 점
역시 이 많은 개념을 기억해야하는 점이 가장 어려웠다.
또 개발을 하면서 들어본 개념은 비교적 쉽게 떠올릴 수 있었으나 조금만 깊게 들어가면 모르는 개념 + 어려운 용어가 나와 반복이 답인 것 같다.