HTTP
HTTP 프로토콜이 무엇인가요?
HTTP는 Hyper Text Transfer Protocol의 약자로, 인터넷에서 데이터를 주고 받을 수 있는 절차와 형식을 규정한 프로토콜
-
웹브라우저와 웹서버 애플리케이션은 HTTP를 이용해 웹페이지 파일을 전송한다.
-
HTTP 파일 전송은 반드시 웹 브라우저의 요청과 이에 대한 웹서버 애플리케이션의 응답으로 이뤄진다.
-
HTTP는 HTML 파일뿐만 아니라, 다양한 종류(JPEG, PNG 등의 이미지 파일, PDF, 워드, 엑셀 등)의 파일을 전송하는 범용적인 프로토콜로도 이용할 수 있다.
-
HTTP는 트랜스포트 층의 프로토콜로서 TCP를 이용하기에, 통신 전에 TCP 커넥션을 맺는다.
HTTP의 요청/응답 모델에 대해 설명해주세요. (예시는 하단 헤더 부분 참고)
HTTP의 통신 원리는 웹브라우저(클라이언트)가 웹서버 애플리케이션(서버)에 HTTP 요청 메시지를 보내면, 웹서버 애플리케이션이 HTTP 응답 메시지를 보내는 것이다.
HTTP 요청
HTTP 요청의 형식은 리퀘스트 라인, 메시지 헤더, 엔티티 바디로 이루어진다.
- 리퀘스트 라인은 HTTP 리퀘스트의 첫 줄로, 웹서버에 대한 실제 처리 요청을 전달하며, 메소드, URI 버전으로 구성된다.
- 메시지 헤더는 리퀘스트 라인에 이어지는 여러줄의 텍스트로, 웹브라우저의 종류와 버전, 대응하는 데이터 형식 등의 정보를 기술한다.
- 엔티티 바디는 메시지 헤더와 뒤이어 나오는 공백 라인 이후 나오는 부분으로, POST 메소드로 웹브라우저에 데이터를 보낼 떄 사용된다.
HTTP 응답
HTTP 응답의 형식은 리스폰스 라인, 메시지 헤더, 엔티티 바디로 이루어진다.
- 리스폰스 라인은 HTTP 리스폰스 첫 줄로, 웹브라우저의 요청에 대한 응답을 전달하며, HTTP 버전과 상태코드, 설명문으로 구성된다.
- 메시지 헤더는 리스폰스 라인에 이어지는 여러줄의 텍스트로, 요청에 대한 추가 정보를 제공하거나, 응답과 관련된 메타데이터를 포함한다.
- 엔티티 바디는 메시지 헤더와 뒤이어 나오는 공백 라인 이후 나오는 부분으로, 요청된 리소스의 내용이나 추가 데이터를 포함한다.
HTTP 메서드
웹 브라우저(클라이언트)가 웹서버 애플리케이션(서버)에 수행하길 원하는 동작을 나타낸다.
각 메서드는 다른 용도와 특징을 가지고 있기에, 차이를 이해하고 적절한 상황에서 사용하는 것이 중요하다.
| 메서드 | 의미 |
|---|---|
| GET | 서버가 클라이언트에서 지정된 리소스를 검색한다. |
| POST | 클라이언트가 서버에 데이터를 전송하여 새 리소스를 생성하거나, 서버의 상태를 변경하도록 요청한다. |
| PUT | 지정된 리소스를 클라이언트가 제공한 데이터로 완전히 대체한다. 만약 지정된 리소스가 없다면 새로 생성할 수 있다. |
| PATCH | 리소스의 일부분만 수정하고자 할 때 사용한다. |
| DELETE | 지정된 리소스를 삭제한다. |
| HEAD | 지정된 리소스의 헤더만 가져온다. |
| OPTIONS | 해당 리소스에서 사용가능한 HTTP메서드를 나열한다. |
| CONNECT | 네트워크 연결을 설정하기 위해 사용한다. |
| TRACE | 요청과 응답 메시지를 디버깅하기 위해 사용한다. |
HTTP 메서드중 GET과 POST의 차이점은 뭔가요?
- 목적: GET 메서드는 서버에서 정보를 조회하기 위해 사용되며, POST 메서드는 서버에 새로운 리소스를 생성하거나 서버의 상태를 변경하기 위해 사용한다.
- 멱등성: GET 메서드는 같은 요청을 여러 번 보내도 동일한 결과를 얻는다. 반면에 POST 메서드는 같은 요청을 여러 번 보낼 경우, 여러 개의 리소스가 생성되거나 상태 변경이 반복될 수 있다.
- 캐싱: GET 메서드는 캐시될 수 있다. 이는 웹 브라우저나 프록시 서버에서 자주 요청되는 데이터를 저장하고 빠르게 제공하기 위한 기능이다. POST 메서드는 캐시되지 않는다.
- URL에 데이터 포함: GET 메서드는 데이터를 URL의 쿼리 파라미터에 포함시킨다. POST 메서드는 데이터를 요청 본문에 포함시키며, URL에는 나타나지 않는다.
- 데이터 크기: GET 메서드는 URL에 데이터를 포함시키기 때문에, 데이터 크기에 제한이 있다. POST 메서드는 요청 본문에 데이터를 포함시키므로, 상대적으로 더 큰 데이터를 전송할 수 있다.
PUT과 PATCH의 차이점은 뭘까요?
- 리소스 수정 방식: PUT 메서드는 전체 리소스를 클라이언트가 제공한 데이터로 완전히 대체한다. 반면 PATCH 메서드는 리소스의 일부분만 수정하는 데 사용한다.
- 멱등성: PUT 메서드는 같은 요청을 여러 번 보내도 동일한 결과를 얻는다. 반면 PATCH 메서드는 같은 요청을 여러 번 보낼 경우, 부분 수정이 반복될 수 있다.
- 효율성: PUT 메서드는 전체 리소스를 대체하기 때문에, 수정할 부분이 작더라도 전체 데이터를 전송해야 합니다. 반면 PATCH 메서드는 수정하려는 부분의 데이터만 전송하므로, 네트워크 효율성이 높습니다.
HTTP 상태 코드가 뭔가요? 알고 있는 상태 코드 몇가지 알려주세요.
HTTP 상태 코드는 서버가 클라이언트에게 응답의 상태를 알려주는 3자리 숫자다.
| 상태 코드 | 설명 |
|---|---|
| 1xx (정보) | 요청이 수신되어 처리 중임을 나타낸다. |
| 100 Continue | 클라이언트는 요청을 계속하거나 무시할 수 있다. 서버는 이 요청에 응답할 준비가 되었음을 알린다. |
| 2xx (성공) | 요청이 성공적으로 수신, 이해 및 처리되었음을 나타낸다. |
| 200 OK | 요청이 성공적으로 처리된 경우이며, 응답은 메서드에 따라 다른 정보를 포함한다. |
| 201 Created | 요청이 성공적으로 처리되었고, 새로운 리소스가 생성된다. |
| 204 No Content | 요청이 성공적으로 처리되었지만, 응답 본문에 보낼 데이터가 없다. |
| 3xx (리다이렉션) | 해당 리소스에서 사용가능한 HTTP메서드를 나열한다. |
| 301 Moved Permanently | 네트워크 연결을 설정하기 위해 사용한다. |
| 302 Found | 요청한 리소스가 일시적으로 다른 위치로 이동한다. 새로운 URL은 응답 내 Location 헤더에 제공된다. |
| 4xx (클라이언트 오류) | 클라이언트의 요청이 잘못된 형식이거나 처리할 수 없음을 나타낸다. |
| 400 Bad Request | 클라이언트의 요청이 잘못된 경우로, 서버가 요청을 이해할 수 없다. |
| 401 Unauthorized | 클라이언트는 요청한 리소스에 대한 인증이 필요하다. |
| 403 Forbidden | 클라이언트는 요청한 리소스에 대한 권한이 없는 경우로, 인증과는 별개로, 리소스에 대한 접근이 거부된다. |
| 404 Not Found | 요청한 리소스를 찾을 수 없는 경우로, 주소가 잘못되었거나, 리소스가 삭제되었을 수 있다. |
| 5xx (서버 오류) | 서버가 요청을 처리하는 데 실패했음을 나타낸다. |
| 500 Internal Server Error | 서버에 오류가 발생하여 요청을 처리할 수 없다. |
| 502 Bad Gateway | 서버가 게이트웨이로부터 잘못된 응답을 수신했음을 의미합니다. 인터넷상의 서버가 다른 서버로부터 유효하지 않은 응답을 받은 경우 발생한다. |
| 503 Service Unavailable | 서버가 일시적으로 요청을 처리할 수 없는 경우로, 일반적으로 서버 과부하나 일시적인 유지보수로 인해 발생한다. |
| 504 Gateway Timeout | 웹페이지를 로드하거나 브라우저에서 다른 요청을 채우려는 동안 한 서버가 액세스하고 있는 다른 서버에서 적시에 응답을 받지 못했음을 의미한다. |
HTTP 헤더가 뭘까요? 알고 있는 헤더 몇 가지 설명해주세요.
HTTP 헤더는 클라이언트와 서버 간의 통신에서 추가 정보를 교환하는데 사용되며, 다양한 목적과 기능을 가지고 있다.
HTTP 요청 헤더
// 리퀘스트 라인
POST /search HTTP/1.1
// 메시지 헤더
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
Accept-Language: ko-KR,ko;q=0.8,en-US;q=0.6,en;q=0.4
// 엔티티 바디(POST 메서드가 아닌 경우 공백)
q=HTTP%20POST%20%EA%B8%B0%EB%B2%95리퀘스트 라인
- HTTP 메서드: POST
- 요청 대상(URI): /search
요청 대상은 서버에서 요청을 처리하기 위해 필요한 리소스의 위치를 나타내며, 이 경우에는 /search라는 경로에 요청을 보낸다. - HTTP 버전: HTTP/1.1
HTTP 프로토콜 버전을 나타내며, 여기서는 HTTP/1.1 버전을 사용하고 있다.
주요 메시지 헤더
- Accept: 클라이언트가 이해할 수 있는 컨텐츠 타입을 나열한다.
- Accept-Encoding: 클라이언트가 지원하는 인코딩 방식을 나열한다.
- Accept-Language: 클라이언트가 선호하는 언어를 나열한다.
- Authorization: 클라이언트의 인증 정보를 포함한다.
- Cache-Control: 캐싱 동작을 지정한다.
- Connection: 네트워크 연결의 관리 방식을 나타낸다.
- Content-Length: 요청 본문의 크기를 바이트 단위로 나타낸다.
- Content-Type: 요청 본문의 미디어 타입을 나타낸다.
- Cookie: 서버에 저장된 쿠키를 전송한다.
- Host: 요청이 전송되는 서버의 도메인 이름과 포트 번호를 나타낸다.
- Referer: 현재 요청을 발생시킨 웹 페이지의 주소를 나타낸다.
- User-Agent: 클라이언트의 소프트웨어(웹 브라우저)에 대한 정보를 나타낸다.
엔티티 바디
- q: 검색어를 나타내는 파라미터로 q는 query(질의)의 약자
- HTTP%20POST%20%EA%B8%B0%EB%B2%95: URL 인코딩된 검색어로 URL 인코딩은 특수 문자나 공백 등을 안전하게 전송하기 위해 사용되는 인코딩 방식이다. 이 경우, %20은 공백을 나타내고 %EA%B8%B0%EB%B2%95은 한글 "기법"을 URL 인코딩한 것이다.
=> 이를 디코딩한 원래 검색어: 'HTTP POST 기법'
HTTP 응답 헤더
// 리스폰스 라인
HTTP/1.1 200 OK
// 메시지 헤더
Date: Sun, 16 Apr 2023 12:28:53 GMT
Server: gws
Content-Type: text/html; charset=UTF-8
Content-Length: 3000
// 엔티티 바디
(검색 결과를 포함한 HTML 문서 내용)리스폰스 라인
- HTTP 버전: HTTP/1.1
- 상태 코드: 200
- 상태 메시지: OK
상태 코드를 설명하는 짧은 텍스트 메시지
상태 메시지는 상태 코드를 설명하는 짧은 텍스트 메시지입니다. 200 상태 코드의 경우, 상태 메시지는 'OK'입니다. 이 메시지는 상태 코드에 대한 추가적인 설명을 제공합니다.
주요 메시지 헤더
- Access-Control-Allow-Origin: 자원에 접근할 수 있는 도메인을 지정한다.
- Cache-Control: 캐싱 동작을 지정한다.
- Content-Disposition: 응답 본문을 처리하는 방식을 제안한다. (예: 파일 다운로드)
- Content-Encoding: 응답 본문의 인코딩 방식을 나타낸다.
- Content-Length: 응답 본문의 크기를 바이트 단위로 나타낸다.
- Content-Type: 응답 본문의 미디어 타입이다.**
심화
HTTP의 무상태성(Stateless)에 대해서 설명해주세요.
클라이언트와 서버 간의 통신에서 상태 정보를 유지하지 않는 것을 의미
특징
- 서버의 부하를 줄일 수 있다.(클라이언트에 대한 상태정보를 유지하지 않기에)
- 캐시를 이용하여 성능을 개선할 수 있다.(같은 리소스 다시 요청시 캐시에서 데이터를 가져옴)
- 일부 웹앱에서 문제 발생가능성이 있다.(이는 쿠키나 세션방식으로 해결)
HTTP Keep-Alive에 대해서 설명해주세요.
클라이언트와 서버 간에 연결을 끊지 않고 유지하는 것을 의미
특징
- 연결을 유지하므로, 처리속도가 개선된다.
- 연결을 다시 설정하는데 필요한 오버헤드를 줄여, 서버의 부하를 감소시킨다.
- HTTP/1.0부터 사용 가능하며, HTTP/1.1에서는 기본적으로 활성화되어 있습니다. 그러나 모든 클라이언트와 서버가 HTTP Keep-Alive를 지원하는 것은 아니기 때문에, 일부 상황에서는 적용되지 않을 수 있다.
HTTP 파이프라이닝에 대해서 설명해주세요.
HTTP(Hypertext Transfer Protocol)에서 요청과 응답을 처리하는 방식 중 하나로, 연속된 요청을 일괄적으로 보내고 응답을 일괄적으로 받는 방식
특징
- 연속된 요청 처리가 가능하다
- 대역폭을 효율적으로 사용할 수 있다
- 몇 가지 제약사항이 있다(서버는 요청을 순서대로 처리하지 않고, 동시에 처리해야 하므로, 요청의 순서가 중요한 경우에는 사용하지 않을 것 / HTTP 파이프라이닝을 지원하지 않는 서버도 있음)
HTTP/1.1, HTTP/2, HTTP/3 각각의 특징에 대해 설명해주세요.
HTTP/1.1
- 연결마다 하나의 요청과 응답만 처리 가능하고, 여러 연결을 사용하여 병렬로 처리한다.
- Keep-Alive 기능을 사용하여 연결을 재활용할 수 있다.
- 브라우저와 서버 간의 통신에서 오버헤드가 크다.
HTTP/2
- 하나의 연결에서 여러 요청과 응답을 처리할 수 있다.
- 요청과 응답을 이진 데이터로 전송하여 처리 속도를 개선한다.
- 헤더 압축 기능을 사용하여 오버헤드를 줄인다.
- 서버 푸시 기능을 지원하여 필요한 데이터를 미리 전송할 수 있다.
HTTP/3
- UDP(User Datagram Protocol)를 기반으로 한 새로운 프로토콜인 QUIC(Quick UDP Internet Connection)을 사용한다.
- 연결마다 하나 이상의 요청과 응답을 처리할 수 있다.
- 헤더 압축과 요청과 응답의 다중화를 지원하여 처리 속도를 개선한다.
- HTTP/2에서는 필요한 데이터를 서버에서 클라이언트로 푸시할 수 있었지만, HTTP/3에서는 클라이언트가 필요한 데이터를 요청하고 서버가 응답을 보내는 방식으로 동작한다.
HTTP에서 캐싱을 구현하는 방법에는 어떤 것들이 있나요?
-
웹 브라우저 캐시: 브라우저는 사용자가 방문한 웹 페이지의 캐시를 유지합니다. 사용자가 같은 페이지에 다시 방문할 경우, 캐시에서 데이터를 가져오므로 서버로부터 데이터를 다시 받아올 필요가 없어 처리 속도가 빨라집니다.
-
프록시 캐시: 프록시 서버는 클라이언트의 요청을 받아서 서버로 전달하고, 서버로부터 받은 응답을 클라이언트에게 전달합니다. 이때 프록시 서버는 응답을 캐싱하여, 이후에 같은 요청이 들어올 경우 캐시된 응답을 전달합니다.
-
게이트웨이 캐시: 게이트웨이는 클라이언트와 서버 간에 위치하여, 서버의 역할을 대신합니다. 이때 게이트웨이는 서버로부터 받은 응답을 캐싱하여, 이후에 같은 요청이 들어올 경우 캐시된 응답을 전달합니다.
-
CDNs(Content Delivery Networks) 캐시: CDN은 전세계에 분산된 서버를 통해 컨텐츠를 제공하는 서비스입니다. 이때 각각의 서버는 자체적으로 캐시를 유지하므로, 같은 컨텐츠를 요청하는 클라이언트에게 캐시된 컨텐츠를 전달하여 처리 속도를 빠르게 합니다.
HTTPS
HTTPS에 대해서 설명해주세요.
HTTPS (Hyper Text Transfer Protocol Secure)는 기본 HTTP 프로토콜에 보안 기능이 추가된 버전이다.
HTTPS는 데이터를 암호화하여 클라이언트와 서버 간에 전송되는 정보를 보호한다.
이를 통해 중간자 공격(Man-in-the-middle attack)과 같은 공격을 방지하고, 개인 정보와 같은 민감한 데이터의 안전성을 높인다. HTTPS는 주로 웹사이트, 웹 애플리케이션 및 API 등에서 사용된다.
SSL/TLS이 뭔가요?
HTTPS에 필요한 보안 기능을 제공하는 암호화 프로토콜
-
SSL (Secure Socket Layer): SSL은 넷스케이프(Netscape)에서 개발한 인터넷 보안 프로토콜이다. SSL은 클라이언트와 서버 간의 통신에 암호화를 적용하여 데이터의 기밀성과 무결성을 보장한다.
-
TLS (Transport Layer Security): TLS는 SSL의 후속 버전으로, 인터넷 엔지니어링 작업 그룹(IETF)에 의해 표준화되었다. TLS는 SSL의 기반 위에서 발전되어 더 강력한 암호화 알고리즘과 기능을 제공한다. TLS는 현재 인터넷 보안의 기본 프로토콜로 사용되고 있다.
심화
HTTPS 암호화 과정에 대해 설명해주세요. (SSL 핸드셰이크에 대해 설명해주세요.)
// 사진 출처: https://hanjungv.github.io/2017-11-07-1_CS_SSL/- Client Hello
- 클라이언트가 SSL 버전 정보, 지원하는 암호화 방식, 무작위 바이트 문자열을 포함하여 서버에게 전송합니다.
- 이미 SSL 핸드셰이크를 했다면 세션을 재사용할 수 있습니다.
- Server Hello
- 서버는 클라이언트의 정보를 받고, 사용할 암호화 방식, 세션 ID, 서버측에서 생성한 무작위 바이트 문자열을 전송합니다.
- 클라이언트에서 인증서를 요구하면 SSL 인증서를 전송합니다.
- 인증서를 받은 클라이언트는 인증서의 신뢰성을 검증하여 공개키를 얻습니다.
- Client Key Exchange
- 클라이언트는 자신이 만든 무작위 바이트 문자열과 서버측에서 전송된 무작위 바이트 문자열을 조합하여 pre master secret 키를 생성합니다.
- pre master secret 키를 공개키 방식으로 암호화하여 서버로 전송합니다.
- Server Key Exchange (optional)
- 서버가 클라이언트로부터 받은 pre master secret 키를 비밀키를 이용하여 복호화하여 master key를 생성합니다.
- Certificate Verify (optional)
- 클라이언트는 서버로부터 받은 인증서를 검증하여 신뢰성을 확인합니다.
- 클라이언트는 서버에 대한 신뢰성을 증명하기 위해 서명을 생성하고, 이를 서버로 전송합니다.
- Change Cipher Spec
- 클라이언트와 서버는 이제부터 생성된 master key를 사용하여 암호화된 통신을 시작합니다.
- Finished
- 클라이언트와 서버는 생성된 세션 키를 사용하여 데이터를 주고 받습니다.
- 통신이 끝나면 세션 키를 폐기합니다.
DNS
DNS가 뭔가요?
DNS (Domain Name System)은 인터넷에서 도메인 이름을 IP 주소로 변환하는 시스템이다.
DNS는 전화번호부와 비슷한 역할을 하며, 사용자가 웹 사이트의 도메인 이름을 입력하면 해당하는 IP 주소로 연결해준다. 인터넷 상에서 각 컴퓨터와 장치는 고유한 IP 주소를 가지고 있는데, DNS는 기억하기 쉬운 도메인 이름을 IP 주소와 매핑하여 사용자들이 쉽게 웹 사이트에 접속할 수 있도록 도와준다.
DNS의 구성요소
- 도메인 네임 스페이스(Domain Name Space): DNS가 저장, 관리하는 계층적 구조
- DNS 서버(=네임 서버): 숫자로 표현된 ip주소로 변환시켜주기 위해서는 도메인 네임 스페이스의 트리 구조에 대한 정보를 가짐.
- 해석기(리졸버): DNS 클라이언트의 요청을 네임 서버에 전달하고, 네임 서버로부터 정보를 받아 클라이언트에게 제공하는 기능을 수행
- DNS 레코드: 도메인 이름과 IP 주소의 매핑 정보를 담고 있는 데이터이다. 주로 A 레코드 (IPv4 주소), AAAA 레코드 (IPv6 주소), CNAME 레코드 (다른 도메인에 대한 별칭), MX 레코드 (메일 서버 정보) 등이 있다.
- DNS 캐싱: 최근에 조회한 도메인 이름과 IP 주소의 매핑 정보를 일시적으로 저장하는 기능이다. DNS 캐싱을 통해 동일한 도메인에 대한 반복적인 요청시간을 줄이고, DNS 서버의 부하를 감소시킨다.
DNS 작동 방식에 대해 설명해주세요.
사용자가 웹 브라우저에 도메인 이름을 입력할 시, 해당 도메인 이름에 대한 IP 주소를 찾아 연결하는 과정으로 이루어진다.
- 사용자가 웹 브라우저에 도메인 이름(예: www.google.com)을 입력한다.
- 브라우저는 먼저 로컬 DNS 캐시에서 해당 도메인 이름에 대한 IP 주소를 찾는다. 로컬 DNS 캐시는 최근에 방문한 웹사이트의 도메인 이름과 IP 주소를 일시적으로 저장한 공간이다. 만약 로컬 DNS 캐시에 해당 정보가 있다면, 바로 IP 주소를 반환하고 과정을 종료한다.
- 로컬 DNS 캐시에 해당 도메인 이름에 대한 정보가 없다면, 브라우저는 설정된 DNS 서버(주로 인터넷 서비스 제공자(ISP)의 DNS 서버)에 IP 주소를 요청한다.
- DNS 서버는 먼저 자신의 캐시에서 해당 도메인의 IP 주소를 찾는다. 있다면 해당 IP 주소를 반환하고 과정을 종료한다.
- 해당 도메인의 IP 주소가 DNS 서버의 캐시에도 없다면, DNS 서버는 루트(root) DNS 서버로 요청을 전달한다.
- 루트 DNS 서버는 최상위 도메인(TLD, Top-Level Domain)에 대한 정보를 가지고 있으며, 이 경우 ".com"에 해당하는 TLD DNS 서버의 주소를 반환한다.
- DNS 서버는 이어서 TLD DNS 서버에 도메인 이름에 대한 IP 주소를 요청한다. TLD DNS 서버는 "google.com"에 해당하는 권한있는(Authoritative) DNS 서버의 주소를 반환한다.
- 마지막으로 DNS 서버는 권한있는 DNS 서버에게 해당 도메인 이름에 대한 IP 주소를 요청한다. 권한있는 DNS 서버는 해당 도메인에 대한 IP 주소 정보를 가지고 있어 이를 반환한다.
- DNS 서버는 받은 IP 주소를 웹 브라우저에 전달하고, 웹 브라우저는 해당 IP 주소의 서버와 연결하여 웹 페이지를 요청하게 된다.
- DNS 서버는 또한 이 IP 주소를 일정 시간동안 캐시에 저장한다. 이로 인해 동일한 도메인에 대한 후속 요청을 더 빠르게 처리할 수 있다.
심화
DNS 질의 종류에 대해 설명해주세요.
- 재귀 질의(Recursive Query)
- 클라이언트가 DNS 서버에게 질의를 보내면, DNS 서버는 질의를 처리할 수 없으면 다른 DNS 서버에게 요청합니다.
- 다른 DNS 서버가 요청을 처리할 수 있으면, 처리 결과를 받아 클라이언트에게 전달합니다.
- 반복 질의(Iterative Query)
- 클라이언트가 DNS 서버에게 질의를 보내면, DNS 서버는 직접 질의를 처리할 수 없으면 다른 DNS 서버의 주소를 반환합니다.
- 클라이언트는 반환된 주소를 통해 다른 DNS 서버에게 질의를 보내고, 이 과정을 반복하여 질의 결과를 찾습니다.
어려웠던 점, 반성하고 싶은 점 / 개선할 방법
어려웠던 점
- 기본적인 질문에 치중하니, 심화 질문을 다룰 시간이 부족헸다.
개선할 방법
- 구체적으로 다루는 것에 초점을 맞추기보다, 핵심적인 내용에 초점을 둬야겠다.
