2주차. 애플리케이션 레이어 HTTP, HTTPS, DNS

[HTTP]

1. HTTP 프로토콜에 대해서 설명해주세요.

HTTP는 웹에서 정보를 주고 받게 해주는 프로토콜입니다.

HTTP는 클라이언트와 서버로 구현됩니다.

클라이언트가 HTTP 메서드로 서버에게 요청을 보내면,

서버는 HTTP 상태코드로 응답하는 방식으로 동작합니다.

 

"HTTP(Hypertext Transfer Protocol)는 웹 프로토콜 중 하나로, 클라이언트와 서버 간 통신을 가능하게 합니다."

 

기본적으로 Request-Response 형태로 동작을 하는데

클라이언트가 서버에게 특정 리소스에 대한 Request를 보내면, 서버는 해당 요청에 대한 Response를 클라이언트에게 전송합니다.

 

 

 

2. HTTP의 요청/응답 모델에 대해 설명해주세요.

클라이언트가 서버에게 요청하고 응답받는 모델입니다.

클라이언트는 HTTP 메서드, 헤더, 바디와 함께 서버에게 HTTP 요청을 보냅니다.

서버는 클라이언트가 보낸 HTTP 메서드, 헤더, 바디에 따른 처리를 수행한다음 상태코드를 통해 HTTP 응답을 클라이언트에게 보냅니다.

클라이언트는 서버로부터 받는 응답을 처리합니다. 예를 들어 HTML을 응답 받았을 경우 화면에 렌더링 합니다.

 

"HTTP의 요청/응답 모델은 웹에서 클라이언트와 서버 간의 기본 통신 패턴을 나타내는데,

이를 통해 동적이고 상호작용적인 웹 애플리케이션을 구현할 수 있습니다."

 

 

1) 클라이언트의 요청

     - 먼저 클라이언트가 서버에게 특정 리소스에 대한 Request를 보냅니다.

 

2) 서버의 처리

     - 서버는 클라이언트의 요청을 받아들이고, 해당 요청에 대한 처리를 시작하는데,

        DB에서 정보를 검색하거나 업데이트, 비즈니스 로직을 수행하는 등의 작업을 포함합니다.

 

3) 서버의 응답

     - 처리가 완료되면 HTTP 응답을 보냅니다.

        Response에는 200 OK, 404 Not Found와 같은 상태코드와 HTML이나 문서, 이미지, JSON 같은 형식의 데이터를 포함합니다.

 

4) 클라이언트의 응답 처리

     - 클라이언트는 서버로부터 받은 응답을 처리하고, 그에 따라 UI를 보여주거나 다음 동작을 수행합니다.

 

 

 

3. HTTP 메서드 중 GET과 POST의 차이점에 대해 설명해주세요.

GET 메서드는 클라이언트가 서버에게 데이터를 요청할때 사용합니다.

GET에 대한 응답으로 서버는 데이터를 클라이언트에게 응답해줍니다.

 

POST 메서드는 클라이언트가 서버에게 데이터를 보낼때 사용합니다.

서버는 POST를 통해 데이터를 받아 데이터를 저장합니다

 

"GET과 POST는 클라이언트가 서버에게 데이터를 요청할 때 주로 사용되는 메서드입니다.

GET은 URL에 데이터를 담아 전송하며, POST는 본문에 데이터를 담아 전송하여 양이 크거나 민감한 데이터를 보낼 때 사용됩니다. GET은 URL에 노출되어 보안에 취약하고, POST는 데이터를 숨겨서 안전한 전송이 가능합니다. 캐싱 측면에서도 보면 GET은 가능하지만, POST는 캐싱이 되지 않아 이전 응답을 재사용할 수 없습니다."

 

 

1) 데이터 전송 방식

     - GET : 데이터를 URL의 쿼리 문자열에 포함하여 전송하지만

     - POST : 데이터를 HTTP body에 포함하여 전송하여,

                     주로 데이터가 크거나 민감한 데이터를 서버에 보낼 때 사용됩니다.

 

2) 데이터 길이

     - GET : URL의 길이에 제한이 있어 전송할 수 있는 데이터 양이 한정적이지만,

     - POST : 일반적으로 길이 제한이 없어서 더 많은 데이터를 전송할 수 있습니다.

 

3) 보안

     - GET : URL에 데이터가 노출되어 브라우저 히스토리, 캐시 등에도 노출될 수 있어 보안에 취약합니다.

     - POST : HTTP body에 담아 전송하므로, GET에 비해 안전합니다.

 

4) 캐싱

     - GET : 요청이 캐시될 수 있으며, 브라우저에서 이전에 받은 응답을 재사용할 수 있습니다.

     - POST : 요청이 캐시되지 않으며, 이전 응답을 재사용할 수 없습니다.

 

 

 

4. HTTP 메서드 중 PUT과 PATCH의 차이점에 대해 설명해주세요.

PUT는 서버 리소스를 전체 수정하고 PATCH는 서버 리소스를 일부 수정합니다.

PUT은 전체 데이터를 수정하는 메서드이므로 멱등이고, PATCH는 구현에따라 멱등이 아닐 수 있습니다.

예를들어 호출할때마다 사용자의 나이를 더하는 PATCH 메서드가 있다면 이는 멱등이 아닙니다.

 

"PUT과 PATCH는 리소스를 업데이트하기 위해 사용되는 메서드입니다.

PUT은 전체 리소스를 업데이트하고 멱등성을 가지며, 데이터를 완전히 교체합니다. 반면에 PATCH는 리소스의 일부만을 업데이트하고 멱등성을 가지지 않습니다. PUT은 전체 데이터를 보내고, PATCH는 업데이트할 부분만을 포함한 데이터를 전송합니다."

 

 

1) 데이터 업데이트 방식

     - PUT : 전체 리소스를 업데이트 합니다.

                   클라이언트가 전송한 데이터로 전체 리소스를 업데이트 합니다.

     - PATCH : 부분 리소스를 업데이트 합니다.

                       클라이언트가 전송한 데이터 중 변경된 부분만을 적용하여 리소스를 업데이트 합니다.

 

2) 멱등성(Idempotency) 차이

     - PUT : 동일한 요청을 여러 번 보내더라도 동일한 상태를 유지합니다.

     - PATCH : 일반적으로 멱등성을 가지지 않으며, 여러 번 요청 시 다른 상태로 변할 수 있습니다.

 

3) 전송 데이터 형태

     - PUT : 전체 리소스를 업데이트 하기 때문에 전체 데이터를 보내야 합니다.

     - PATCH : 업데이트할 부분만을 포함한 데이터를 보내기 때문에 전송되는 데이터 양이 PUT에 비해 작습니다.

 

4) 사용 예시

     - PUT : 블로그 글의 내용을 업데이트할 때 사용될 수 있습니다.

     - PATCH : 제목이나, 카테고리 등 일부 정보만을 업데이트할 때 사용될 수 있습니다.

 

 

 

5. HTTP 상태 코드가 뭔가요? 알고 있는 상태 코드 몇가지 설명해주세요.

HTTP 상태코드는 클라이언트의 요청에 대해 서버가 어떤 결과로 응답했는지 알려줍니다.

서버에서 에러를 응답해줄때 상태코드를 500으로 응답하도록 구현한 적이 있습니다.

 

1) 1-- (Informational, 정보)

     - 100 Continue : 서버가 클라이언트의 일부 요청을 받았으며, 클라이언트는 나머지를 계속 보낼 수 있습니다.

 

 

2) 2-- (Success, 성공)

     - 200 OK : 요청이 성공적으로 처리되었습니다.

     - 201 Created : 새로운 리소스가 성공적으로 생성되었습니다.

     - 204 No Content : 요청은 성공적으로 처리되었지만, 응답에 별도의 내용이 없습니다.

 

 

3) 3-- (Redirection, 리다이렉션)

     - 301 Moved Permanently : 요청한 리소스가 새로운 위치로 옮겨졌으며, 이후의 요청은 새로운 위치(Location: ~)로 보내져야 합니다.

     - 302 Found (or Temporary Redirect) : 리소스가 일시적으로 다른 위치로 이동했으며, 이후의 요청은 여전히 원래 위치로 보내져야 합니다.

 

 

4) 4-- (ClientError, 클라이언트 오류)

     - 400 Bad Request : 클라이언트의 요청이 잘못되었거나 서버에서 이를 인식하지 못했습니다.

     - 403 Forbidden : 요청이 서버에 의해 거부되었습니다. (클라이언트 권한)

     - 404 Not Found : 요청한 리소스를 찾을 수 없습니다.

 

 

5) 5-- (Server Error, 서버 오류)

     - 500 Internal Server Error : 서버가 요청을 처리하는 중에 오류가 발생했습니다.

     - 503 Service Unavailable : 서버가 일시적으로 요청을 처리할 수 없습니다. (과부하 or 유지보수 상태)

     - 505 HTTP Version Not Supported : 요청 HTTP 프로토콜 버전을 서버가 지원하지 않습니다.

 

 

6. HTTP 헤더가 뭘까요? 알고 있는 헤더 몇 가지 설명해주세요.

HTTP 헤더는 클라이언트와 서버가 어떤 행위를 할건지에 대한 부가 정보입니다.

예를 들어 서버가 응답 헤더에 Cache-Control를 추가하여, 응답한 데이터가 캐싱되도록 클라이언트에게 알려줄 수 있습니다.

 

"HTTP 헤더는 HTTP 요청 및 응답 메시지에 부가적인 정보를 포함하는데 사용됩니다. User-Agent 헤더는 클라이언트 소프트웨어의 정보를, Content-Type 헤더는 전송된 데이터의 형식을, Authorization 헤더는 사용자의 인증 정보를, Cookie 헤더는 서버로부터 전달받은 쿠키 정보를, Location 헤더는 리다이렉션 시 새로운 위치를 나타냅니다."

 

 

1) User-Agent 헤더

     - 클라이언트 소프트웨어의 정보를 식별하는데 사용됩니다.

        주로 브라우저의 종류 / 버전 / 운영체제 등의 정보를 담고 있습니다.

 

 

2) Content-Type 헤더

     - 메시지 본문의 미디어 타입을 지정합니다.

        클라이언트에게 전송된 데이터의 형식을 명시합니다.

 

     - ex. "Content-Type: application/json"

 

 

3) Authorization 헤더

     - 요청된 리소스에 접근하기 위한 사용자의 인증 정보를 담고 있습니다.

        주로 id / pw를 암호화하여 전송합니다.

 

 

4) Cookie 헤더

     - 서버로부터 전달받은 쿠키 정보를 포함하고, 이를 통해 클라이언트의 상태를 유지하도록 합니다.

 

 

5) Location 헤더

     - redirection 응답에서 사용되며, 클라이언트에게 새로운 위치로 이동할 것을 알려줍니다.

 

     ex. "Location: https://example.com/new-page"

 

 

 

7. HTTP의 무상태성(Stateless)에 대해서 설명해주세요.

Stateless는 서버가 클라이언트의 정보를 유지하지 않는 특성입니다.

서버는 기본적으로 클라이언트에 대한 정보가 없기 때문에 클라이언트가 누군지 식별할 수 없습니다.

클라이언트를 식별하기 위해 쿠키, 세션과 같은 상태유지 기술을 사용할 수 있습니다.

 

"HTTP의 무상태성은 각각의 클라이언트 요청이 서버에 의해 독립적으로 처리되는 특성을 나타냅니다. 서버는 클라이언트의 상태를 관리하지 않고, 각각의 요청은 이전 요청과 독립적으로 처리됩니다. 이로 인해 서버의 부하가 감소하고 확장성이 향상되며, 클라이언트와 서버 간의 상호작용이 단순하고 유연해지는 장점이 있습니다."

 

HTTP 서버가 클라이언터에게 요청 파일을 보낼 때, 서버는 클라이언트에 관한 어떠한 정보도 저장하지 않는다.

 

 

1) 서버의 부하 감소

     - 서버가 클라이언트의 상태를 추적하고 관리하는 것은 복잡성을 증가시킬 수 있습니다.

        무상태성은 이러한 복잡성을 감소시켜 서버 부하를 줄일 수 있습니다.

 

2) 확장성 향상

     - 서버가 동시에 많은 클라이언트와 통신할 수 있는 확장성을 향상시킵니다.

        각각의 요청은 독립적으로 처리되기 때문에 서버는 특정 클라이언트의 상태를 계속 유지할 필요가 없습니다.

 

 

 

8. HTTP Keep-Alive에 대해서 설명해주세요.

HTTP Keep-Alive는 HTTP 요청/응답시 TCP 연결을 유지하는 기능입니다.

이를 통해 매번 연결을 하지 않아도 여러 개의 요청과 응답을 처리할 수 있기 때문에 웹 응답 속도를 빠르게할 수 있습니다.

 

"HTTP Keep-Alive는 하나의 TCP 연결을 통해 여러 개의 HTTP 요청과 응답을 주고받을 수 있도록 하는 메커니즘입니다. 기본적으로 HTTP는 각각의 요청에 대해 새로운 TCP 연결을 맺고, 해당 요청에 대한 응답을 받은 후에 연결을 종료하는데, Keep-Alive는 이러한 연결의 재사용을 가능케 합니다."

 

cf. HTTP 1.1 버전에서는 기본적으로 활성화 되어 있기 때문에 일반적으로 별도의 설정이 필요하지 않습니다.

 

 

1) 성능 향상

     - 하나의 연결을 재활용함으로써, TCP 연결에 대한 오버헤드를 줄이고 전송 속도를 향상시킬 수 있습니다.

 

2) 연결 지연 감소

     - 여러 개의 리소스가 한 웹 페이지에 포함되어 있을 때, 하나의 연결을 통해 모든 리소스를 가져올 수 있어 연결 지연을 감소시킵니다.

 

3) 서버 부하 감소

     - 여러 요청을 동일한 연결에서 처리할 수 있으므로, 서버의 부하를 감소시킬 수 있습니다.

 

 

 

9. HTTP 파이프라이닝에 대해서 설명해주세요.

요청에 대한 응답을 받기 기다리지 않고 여러개의 요청을 보내는 것입니다.

응답을 기다리지 않기 때문에 서버와 클라이언트간의 대기 시간을 줄일 수 있습니다.

 

"HTTP 파이프라이닝은 클라이언트가 여러 개의 HTTP 요청을 하나의 TCP 연결에서 연속적으로 전송하는 기술을 말합니다. 이를 통해 이전 요청의 응답을 기다리지 않고 여러 요청을 연이어 전송할 수 있어, 전체 응답 시간을 단축시키고 네트워크 성능을 향상시킬 수 있습니다."

 

 

1) 순서

     - 클라이언트가 요청을 수신한 순서대로 서버가 응답을 보내줍니다.

 

2) 성능 향상

     - 여러 개의 요청을 한 번에 보내므로 네트워크 오버헤드가 감소하고 전체 응답 시간이 단축됩니다.

 

 

 

10. HTTP/1.1, HTTP/2, HTTP/3 각각의 특징에 대해 설명해주세요.

"HTTP/1.1은 Keep-Alive를 통한 지속적인 연결을 도입했지만, Head-of-Line Blocking이 발생할 수 있는 문제가 있었습니다.

HTTP/2는 이진 프레임 기반의 병렬 전송을 지원하여 성능을 향상시키고, 서버 푸시와 헤더 압축 등의 기능을 도입했습니다.

HTTP/3는 UDP 기반의 QUIC 프로토콜을 사용하여 연결 설정과 멀티플렉싱을 최적화하고, Head-of-Line Blocking 문제를 완전히 해결하여 빠른 데이터 전송을 지원합니다."

 

 

1) HTTP/1.1

     - Keep-Alive을 통해 여러 요청을 동일한 연결에서 처리할 수 있도록 하였습니다.

     - 파이프라이닝은 지원하지만, Head-of-Line Blocking이 발생할 수 있어 사용이 제한적입니다.

     - 텍스트 기반의 헤더와 상태 코드, 비압축 형태의 데이터 전송을 사용합니다.

 

     - 여러 개의 TCP 연결을 열어서 HOL 블로킹 문제를 해결해왔다.

 

 

2) HTTP/2

     - 이진 프레임 기반으로 설계되어, 각 메시지를 작은 프레임으로 나누고 같은 TCP 연결에서의 요청과 응답 메시지를 인터리빙 합니다.

     - 메시지 우선순위화 / 서버 푸시 / HTTP 헤더 압축 기능을 통해 효율적인 전송을 지원합니다.

          - 메시지 우선순위화 : 요청 프레임의 상대적 우선 순위를 조정할 수 있게 함으로써 애플리케이션의 성능을 최적화 함.

          - Server Push  : 서버가 클라이언트의 요청 없이도 추가적인 객체를 푸시하여 전송할 수 있습니다.

                                      (HTML 기반 페이지가 웹 페이지를 완벽하게 구동시킬 필요가 있는 객체들을 가리킬 수 있기에 가능)

 

     - HTTP/2의 주요 목표 중 하나는 하나의 웹 페이지를 전송하기 위한 병렬 TCP 연결의 수를 줄이거나 제거하는 데 있습니다.

        (이는 서버에서 열고 유지되는 데 필요한 소켓의 수를 줄일 뿐만 아니라, 목표한 대로 TCP 혼잡 제어를 제어할 수 있게 한다.)

 

 

3) HTTP/3

     - UDP를 기반으로 하는 QUIC 프로토콜 위에서 동작하며, 메시지 멀티플렉싱(인터리빙) 및 저지연 연결 설정과 같은 기능을 통해 빠른 데이터 전송을 지원합니다.

 

 

 

 

---

 

 

 

 

[HTTPS]

1. HTTPS에 대해서 설명해주세요.

HTTPS는 HTTP와 달리 SSL, TLS 프로토콜을 통해 데이터를 암호화해서 전송하기 때문에 데이터 보완을 할 수 있는 이점이 있습니다.

 

"HTTPS는 HTTP 프로토콜을 기반으로 하면서 데이터의 암호화, 무결성 보장, 인증 등의 보안 기능을 제공하는 프로토콜입니다."

 

 

 

2. SSL/TLS이 뭔가요?

SSL은 컴퓨터 네트워크에 통신 보안 기능을 제공하는 프로토콜 입니다.

SSL은 일련의 핸드셰이크 과정에서 인증기관, 인증서, 공개키 암호화, 대칭키 암호화 등을 통해 클라이언트-서버간 암호화 통신을 가능하게 해줍니다. TLS는 SSL이 표준화 되면서 바뀐 이름입니다.

 

"SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)은 웹상에서 데이터를 안전하게 전송하기 위한 프로토콜로, 보안 소켓 계층을 구현하는 데 사용됩니다. TLS는 SSL의 취약점을 보완한 버전으로 암호화, 무결성 보장, 상호 인증 등의 기능을 제공하여 웹 브라우저와 웹 서버 간의 통신을 안전하게 합니다."

 

 

1) 암호화

     - 전송되는 데이터를 암호화하여 중간에서의 도청을 방지합니다.

 

2) 무결성 보장

     - 데이터가 중간에서 변경되지 않도록 보장합니다.

 

3) 상호 인증

     - 클라이언트와 서버 간의 상호 인증을 수행하여 신뢰성을 확보합니다.

 

 

 

3. 대칭키 암호화 방식에 대해 설명해주세요.

하나의 키로 데이터를 암호화하고 복호화하는 방식입니다.

 

"대칭키 암호화는 하나의 키를 사용하여 데이터를 암호화하고 복호화하는 방식입니다. 암호화와 복호화에 동일한 키가 사용되기 때문에 키의 안전한 공유와 관리가 중요하며, 속도 면에서는 빠르게 동작하는 특징이 있습니다. 대표적인 대칭키 암호화 알고리즘으로는 AES가 널리 사용되고 있습니다."

 

 

1) 키 공유

     - 암호화와 복호화에 동일한 키가 사용되기 때문에, 통신하는 양쪽 간에 키를 안전하게 공유해야 합니다.

 

2) 속도

     - 일반적으로 빠른 속도로 동작합니다.

 

3) 암호화 알고리즘

     - 대표적인 대칭키 암호화 알고리즘으로는 DES, 3DES, AES 등이 있습니다.

       (AES는 128비트 블록을 사용하고, 128, 192, 256 비트 길이의 키를 사용할 수 있다.)

 

 

 

4. 비대칭키(공개키) 암호화 방식에 대해서 설명해주세요.

공캐 키와 개인 키로 데이터를 암호화하고 복호화하는 방식입니다.

공개 키로 암호화하고 개인 키로 복호화하면 진짜 보안을 위한 목적이고, 공개 키로 복호화하고 개인 키로 암호화하면 인증을 위한 목적입니다.

 

"비대칭키 암호화는 공개키와 개인키를 사용하여 데이터를 암호화하고 복호화하는 알고리즘입니다."

 

 

1) 키 쌍

     - 공개키와 개인키가 한 쌍을 이루어야 합니다. 또한 개인키는 오직 키를 생성한 개인만이 알고 있어야 합니다.

 

2) 인증 및 전자 서명

     - 공개키는 소유자를 인증하고, 전자 서명을 생성하는 데에도 사용됩니다.

        데이터의 무결성을 보장하고 전자 문서의 신뢰성을 확보하는데 이용됩니다.

 

3) 속도와 효율성

     - 대칭키 암호화에 비해 속도가 느리기 때문에, 주로 작은 양의 데이터를 보호하는데 사용됩니다.

     - 보통은 대칭키 암호화로 전자 문서의 내용을 암호화, 그 대칭키를 공개키로 암호화여 전송하는 형태로 활용됩니다.

 

 

 

5. 전자 서명에 대해서 설명해주세요.

전자서명은 비대칭키 암호화 방식에서 개인키로 데이터를 암호화하고 공개키로 복호화 하는 방식입니다.

전자서명이 공개키로 복호화 되는것을 통해 특정 개인인지 신뢰할 수 있습니다.

 

"네트워크에서의 전자 서명은 데이터의 무결성을 보장하고 송신자를 인증하기 위한 보안 기술 중 하나입니다. 이를 통해 데이터가 전송 도중에 변경되지 않았는지를 확인하고, 송신자의 고유성을 인증할 수 있습니다. 주로 비대칭키 암호화 기술을 활용하여 작동하며, 전자 문서 및 전자 계약에서 널리 사용됩니다."

 

 

1) 무결성 보장

     - 데이터가 전송되는 동안 중간에서 변경되지 않았는지를 확인하여, 데이터의 신뢰성을 확보합니다.

 

2) 송신자 인증

     - 전자 서명을 통해 송신자를 고유하게 식별하고 인증할 수 있습니다.

 

3) 비대칭키 암호화 기술

     - 송신자는 개인키를 사용하여 데이터에 서명하고, 수신자는 해당 서명을 검증하기 위해 송신자의 공개키를 사용합니다.

 

 

 

6. ⭐️ HTTPS 암호화 과정에 대해 설명해주세요. (SSL Handshake의 동작 과정을 설명해 주세요.)

1. 웹 서버(사이트)는 서버 정보와 서버의 공개키를 인증 기관에 주면서 인증 요청을 합니다.
2. 인증 기관은 서버로 부터 받은 서버 정보와 공개키를 인증기관의 개인키로 암호화하여 인증서를 만듭니다.
3. 인증 기관은 인증서에 대한 공개키를 브라우저들에게 제공하고, 서버에 인증서를 발급합니다.
4. 클라이언트가 웹 서버에 접속하면, 먼저 서버로부터 인증서를 받습니다.
5. 클라이언트는 인증 기관으로부터 받은 공개키를 사용해 인증서를 검증합니다.
6. 신뢰 할만한 인증기관이라면, 대칭키를 만들고, 인증서에 들어있던 서버의 공개키를 사용해 대칭키를 암호화하여 서버에 전송합니다.
7. 서버는 안전하게 클라이언트가 만든 대칭키를 받습니다.
8. 이제 클라이언트와 서버는 안전하게 공유된 대칭키를 통해 암호화 통신이 가능해집니다.

 

"SSL Handshake는 HTTPS 암호화 과정의 초기 단계로, 클라이언트와 서버 간에 안전한 통신을 설정합니다. 클라이언트가 서버에게 SSL 연결을 요청하는 ClientHello 메시지를 보내고, 서버는 이에 대한 응답으로 ServerHello를 보냅니다. 이후에는 서버 인증, Pre-Master Secret 교환, Session Key 생성 등의 단계를 거쳐 안전한 통신을 위한 환경을 마련합니다."

 

 

1) ClientHello

: 클라이언트가 서버에게 SSL 연결을 시작하고자 한다는 메시지를 보냅니다.

이 메시지에는 클라이언트가 지원하는 SSL/TLS 버전, 암호화 알고리즘, 무작위 데이터(Nonce) 등이 포함됩니다.

 

2) SeverHello

:  서버는 클라이언트가 보낸 정보 주에서 사용할 SSL/TLS 버전, 암호화 알고리즘, 무작위 데이터(Nonce) 등을 선택하여 응답합니다.

 

3) 인증 및 키 교환

: 서버는 클라이언트에게 서버 인증서를 제공합니다.

클라이언트는 이 인증서의 유효성을 확인하고, 서버의 공개키를 사용하여 PMS(Pre-Master Secret)을 암호화하여 서버에게 전송합니다.

 

4) Master Secret 생성

: 클라이언트와 서버는 각자의 Nonce와 클라이언트가 생성한 Pre-Master Secret을 조합하여 Maser Secret을 생성합니다.

 

5) Session Key 생성

: Master Secret을 이용하여 클라이언트와 서버는 각자의 Session Key를 생성합니다.

만들어진 세션키는 실제 데이터를 암호화하고 복호화하는데 사용됩니다.

 

6) 암호화 설정 완료

: 클라이언트와 서버는 Handshake 과정이 완료되었음을 서로에게 알리고,

이제부터는 생성된 세션키를 사용하여 데이터를 암호화하고 복호화합니다.

 

 

 

 

---

 

 

 

 

[DNS]

1. ⭐️ DNS가 뭔가요?

DNS는 도메인 네임을 IP 주소로 변환해주는 프로토콜이자 계층형 구조로 구현된 분산 데이터베이스 입니다.

호스트가 도메인 네임에 대한 IP 주소를 요청하면 DNS은 계층 질의를 통해 IP 주소를 얻어다가 줍니다. 만약 로컬 DNS에 해당 IP 주소가 캐싱되어 있다면 바로 받습니다.

빠른 응답을 제공하기 위해 DNS는 UDP 기반으로 동작하고 DNS 서버들은 요청 정보를 캐싱해둡니다.

 

"DNS(Domain Name System)은 컴퓨터 네트워크에서 호스트 이름과 IP 주소 간의 대응 관계를 관리하고 조회하는 시스템입니다.

DNS가 제공하는 서비스로는 호스트명-IP 주소 변환 서비스 / 호스트 별칭 서비스 / 메일서버 별칭 서비스 / 부하 분산 서비스 등이 있습니다."

 

 

1) Hostname to IP Address (호스트명-IP 주소 변환 서비스)

: 사용자의 호스트명(도메인명)을 32비트 IP 주소로 변환합니다.

 

2) Host Aliasing (호스트 별칭 서비스)

: 사용자의 호스트 별칭(alias)을 복잡한 정규 호스트명으로 변환합니다.

 

3) Mail Server Aliasing (메일서버 별칭 서비스)

: 사용자의 메일서버 별칭을 복잡한 정규 호스트명으로 변환합니다.

 

4) Load Distribution (부하 분산 서비스)

: 동일 도메인명으로 서로 다른 IP 주소의 다중 복제 서버를 배치하여,

  동일 도메인명에 대한 DNS 요청에 대해 다른 IP 주소를 돌아가며 응답합니다.

 

 

 

2. DNS 작동 방식에 대해 설명해주세요.

사용자가 웹 브라우저에서 도메인 이름을 입력합니다.

브라우저는 해당 도메인을 DNS 서버에 보내서 IP 주소를 요청합니다.

DNS는 IP주소를 찾아서 브라우저에 보내고, 브라우저는 IP주소를 통해 서버에 요청을 보냅니다.

 

"사용자가 호스트 이름을 입력하면, 로컬 DNS 캐시에서 정보를 찾고 없으면 DNS 쿼리를 통해 루트 DNS 서버부터 Authoritative DNS 서버까지 차례로 정보를 조회하며 호스트 이름을 IP 주소로 변환합니다."

 

+. DNS 프로토콜은 UDP 상에서 수행되고 포트 번호 53을 이용한다.

 

 

 

1) 호스트 이름의 해석

: 먼저 로컬 DNS 캐시에서 호스트 이름과 IP 주소의 대응 관계를 검색합니다.

 

2) 로컬 DNS 캐시

: 호스트 이름과 대응되는 IP 주소가 있다면, IP 주소를 응답합니다.

  만약 로컬 캐시에 해당 정보가 없다면, DNS 쿼리를 수행해야 합니다.

 

3) DNS 쿼리 전송

: 로컬 캐시에 해당 정보가 없거나 유효하지 않다면, 클라이언트는 DNS 쿼리를 DNS 서버에 전송합니다.

  (일반적으로 ISP가 제공하는 DNS 서버 주소 또는 직접 설정한 DNS 서버 주소 이용)

 

4) 루트 DNS 서버

: 루트 DNS 서버에게 호스트 이름의 최상위 도메인(TLD) 정보를 요청합니다.

  루트 DNS 서버는 해당 도메인의 TLD DNS 서버주소를 응답합니다,

 

5) TLD DNS 서버

: TLD DNS 서버에게 도메인 정보를 요청합니다.

  TLD DNS 서버는 해당 도메인의 Authoritative DNS 서버 주소를 응답합니다.

 

6) Authoritative(책임) DNS 서버

: Authoritative DNS 서버에 도메인의 IP 주소를 요청합니다.

  Authoritative DNS 서버는 최종적으로 호스트 이름에 대응되는 IP 주소를 응답합니다.

 

7) 응답 및 로컬 DNS 캐시 갱신

: 클라이언트는 받은 IP 주소를 사용하여 통신을 시작하고, 받은 정보는 로컬 DNS 캐시에 저장됩니다.

  (IP 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화한다.)

 

 

 

3. DNS 질의 종류에 대해 설명해주세요.

재귀적 질의는 도메인 네임에 해당하는 IP주소를 통해 DNS가 다른 DNS에게 재귀적으로 IP 주소를 물어보는 것을 뜻합니다.

반복적 질의는 IP 주소를 찾기 위해 반복적으로 질의하는 것입니다.

로컬 DNS가 루트 DNS에게 IP주소를 물어봤는데 없으면 TLD DNS에게 물어보고 또 없으면 authoriative DNS에 반복적으로 물어보는 것을 예시로 들 수 있습니다.

 

"DNS 질의는 다양한 유형이 있으며, 각각의 질의 유형은 특정 정보를 얻기 위해 사용됩니다. A 질의는 호스트 이름을 IPv4 주소로 변환하고, CNAME 질의는 호스트 이름을 다른 호스트 이름으로 매핑합니다. MX 질의는 메일 서버의 주소를 얻기 위해 사용되며, NS 질의는 도메인의 네임 서버 정보를 조회합니다. 이외에도 PTR, SOA, TXT 등 다양한 질의 유형이 있습니다."

 

 

1) A 질의

: 호스트 이름(도메인)을 IPv4 주소를 찾는데 사용됩니다.

 

2) AAAA

: 호스트 이름을 IPv6 주소로 찾는데 사용됩니다.

 

3) CNAME(Canonical Name)

: 별칭(Alias) 호스트 이름에 대한 정규 호스트 이름을 찾는데 사용됩니다.

 

4) MX(Mail Exchange)

: 메일을 전송하기 위한 메일 서버의 정규 호스트 이름을 찾는데 사용됩니다.

 

5) NS(Name Server)

: 호스트의 책임 DNS 서버 정보를 얻는데 사용됩니다.

 

6) PTR(Pointer)

: IP 주소를 호스트 이름으로 변환하는데 사용됩니다.

 

 

 

4. DNS 서버에게 IP 주소를 요청할 때, 왜 UDP를 사용하나요?

DNS는 신뢰성보다 속도가 더 중요한 서비스이기 때문에 연결 설정에 드는 비용이 없는 UDP를 사용합니다.

DNS는 연결 상태를 유지할 필요가 없고, TCP보다 많은 클라이언트를 수용할 수 있는 UDP를 사용합니다.

 

"DNS에서 IP 주소를 요청할 때 UDP를 사용하는 이유는 주로 성능과 효율성에 있습니다. UDP는 간결하고 빠른 통신을 지원하며, DNS의 작은 크기의 요청과 응답에 적합합니다. 또한 연결 설정이 필요 없는 비연결형 프로토콜이며, 적은 오버헤드와 부하 분산에도 유리합니다."

 

 

 

5. DNS 레코드가 무엇인가요?

DNS 서버는 데이터베이스 서버의 한 유형이며, 클라이언트로부터 질의를 받았을 때 그에 맞는 데이터를 응답해야 합니다. 데이터베이스의 한 항목(row)을 DNS 서버에서는 리소스 레코드라고 부릅니다.

• A
  • IP 주소와 도메인 주소를 매핑할 때 사용하는 레코드입니다.
• CNAME
  • 기존 도메인에 별명을 붙인 레코드입니다.
• TXT
  • 텍스트를 입력할 수 있는 레코드입니다.
  • 개인 프로젝트에서 무료 SSL 인증서를 등록하는 과정에서 사용하였습니다.

 

"DNS 레코드는 도메인과 관련된 정보를 저장하고 반환되는 단위입니다. 클라이언트의 DNS 질의에 대한 응답으로 특정 레코드 유형의 데이터를 제공하는데, A / AAAA / MX / NS 레코드 등이 있습니다."

 

+. 호스트를 가진 모든 기관은 호스트 이름을 IP 주소로 매핑하는 공개적인 DNS 레코드를 제공해야 합니다.

기관의 책임 DNS 서버는 이 DNS 레코드를 갖고 있다.