[저장용] HTTP 관련 면접 질문 정리

아래 질문들은 흔하게 나오는 질문들인데, 얼마나 알고 있는지 문항을 보고 답변해봅시다.

---

1. HTTP 에 대해 설명해보세요.

1. HTTP는 하이퍼텍스트를 클라이언트와 서버 간에 어떻게 통신할지에 대해 정해놓은 규칙(프로토콜) 입니다.

2. 요청과 응답으로 구성되어있고, 일반적으로 80번 포트를 사용합니다.

3. 기본적으로 상태를 유지하지 않습니다. 따라서 어떤 웹 서비스에서 상태를 유지하려면 세션, 토큰, 쿠키등의 추가 자원을 활용해야 합니다. 다만 이러한 무상태성 덕분에 스케일아웃 방식의 서버 확장에 용이합니다.

4. 연결도 유지하지 않습니다. 클라이언트는 서버측에 어떠한 요청을 보내고, 서버는 응답을 한 후 바로 연결을 끊습니다. 다만 HTTP/1.1 버전 이상에서는 커넥션 헤더의 Keep-Alive 옵션을 통해 일정 시간 연결을 유지할 수도 있습니다.

---

1-1. 상태를 유지하려면 어떻게 해야 하나요?

상태를 유지하려면 쿠키, 토큰, 세션을 활용하는 방법이 있습니다. 쿠키의 경우, 브라우저 쿠키에 유저 관련 정보를 담아두고 있다가 요청할 때 쿠키를 포함하여 요청하면 서버가 판독하여 알맞은 응답을 합니다. 토큰의 경우는 액세스 권한이 있는 토큰을 클라이언트가 가지고 있다가 요청에 포함하여 보냅니다. 세션의 경우는 세션 아이디를 쿠키에 기록해두고 있다가 요청마다 자동 포함되어 보내집니다.

---

1-2. 쿠키, 토큰, 세션의 차이는 뭔가요?

쿠키와 토큰의 차이는 쿠키는 쿠키저장소에 보관됩니다. 토큰은 로컬스토리지, 세션스토리지, 메모리 등 어디에도 저장될 수 있습니다. 또한 쿠키는 요청에 자동으로 포함되어 전송되지만 토큰은 클라이언트가 직접 포함시켜 전송해야 합니다. 세션은 쿠키에 세션 아이디가 저장되어 있다가, 유저가 요청할 경우 서버 세션에서 세션 아이디에 매핑되어있는 값을 참조하여 판별합니다.

---

1-3. 서버 세션을 활용하는 경우 상태가 서버측 세션에 저장될텐데, 그러면 여러 서버와 여러 세션이 존재하는 상황에서 유저의 상태를 어떻게 매번 정확하게 알 수 있나요?

서버가 여러 대일 때 유저 상태를 유지하기 위해서는 세션 간의 데이터를 일치시켜야 하는 문제가 발생합니다. 이 때 만약 서버마다 개별적으로 세션을 생성했다면 하나의 서버에 유저 정보가 종속되는 상황이 벌어집니다. 그렇게 되면 트래픽 발생 등의 이유로 서버가 바뀌었을 때 기존의 유저 정보가 소실되는 상황이 발생합니다. 세션 정합성을 유지하기 위해 레디스 등의 도구를 써서 공통 세션을 외부에 만들어놓고, 서버는 외부의 공통 세션을 참조하도록 하는 방법이 있습니다.

---

2. HTTP 연결이 어떻게 이루어지는지 설명해보세요.

1. 3-way handshake 과정을 통해 TCP/IP 연결이 됩니다.

2. 클라이언트가 연결하기 위해 ACK 패킷을 보내면, 서버는 응답하기 위해 SYN/ACK 패킷으로 응답하고, 그를 수신한 클라이언트는 다시 서버로 SYN 패킷을 보내 연결합니다.

3. HTTP/1.0 버전에서는 HTML, CSS, Javascript 등을 모두 수신하기 위해 연결을 끊었다가 다시 연결하기를 반복했기 때문에 매우 비효율적이었습니다. 이는 HTTP/1.1 버전에서 모든 자원을 받고 연결을 끊는 방식으로 개선되었습니다.

---

2-1. 주소창에 www.naver.com 을 입력했을 때 벌어지는 일에 대해 설명해보세요.

1. 해당 도메인 주소와 맞는 아이피 주소로 TCP/IP 요청을 보내고, 연결을 해야 합니다.

2. 그러기 위해 브라우저는 우선 브라우저 DNS 캐시를 참조합니다. 만약 거기에 아이피 주소가 없다면 OS의 DNS 캐시를 참조하고, 거기에도 없다면 공유기 등의 라우터가 있는 경우 라우터 캐시를 참조합니다. 거기에도 없다면 ISP에서 관리하는 로컬 DNS 서버의 캐시를 참조합니다. 모두 없다면 다른 DNS 서버에 질문해가며 주소를 찾아야 합니다..

3. 로컬 DNS 서버는 다른 DNS 서버에 질문을 합니다. 루트 DNS 서버에다가 네이버에 해당하는 주소를 요청합니다. 여기서 루트 DNS 서버는 네이버에 해당하는 주소를 알지 못하고, 대신 .com 으로 끝나는 도메인에 해당하는 주소 목록을 반환합니다.

4. .com 을 관리하는 DNS 서버에 다시 요청합니다. 여기서도 네이버에 해당하는 주소는 알지 못하고, 대신 naver.com 으로 끝나는 도메인에 해당하는 주소 목록을 반환합니다.

5. naver.com DNS 서버는 네이버에 해당하는 주소를 가지고 있으며 그 밖에도 mail.naver.com 등 다른 도메인에 해당하는 주소도 가지고 있습니다.

6. 이제 해당 주소를 가지는 서버와 TCP/IP 연결을 수립합니다.

7. HTTP 프로토콜을 통해 HTML 문서를 주고받습니다.

8. 받은 HTML 문서를 화면에 그립니다.

---

3. TCP와 UDP의 차이에 대해 설명해보세요.

1. TCP 연결은 연결 지향적 특성을 가집니다. 3-way handshake 과정을 통해 데이터 전송의 신뢰성을 보장합니다. 신뢰성 보장, 흐름 제어, 혼잡 제어에 쓰이는 값들이 헤더에 포함되고, 이 값들을 참조해서 패킷의 순서를 보장합니다. 따라서 UDP 연결에 비해 상대적으로 헤더의 크기가 크고 속도가 느립니다.

2. UDP 연결은 비연결 지향적입니다. 패킷이 전송될 때 따로 경로를 지정하지 않고 날아가기 때문에 데이터를 빠르게 보낼 수 있습니다. TCP 에 비해 헤더의 크기가 작고 속도도 빠르지만, 데이터 전송의 신뢰성을 보장하지 않기 때문에 중간에 패킷이 누락되어도 수신측에서는 모를 수 있습니다.

3. 이러한 특성 때문에 TCP 연결은 웹 페이지, 파일, 메일 전송 등에 사용되고 UDP 연결은 웹 스트리밍, 온라인 게임 등에 사용됩니다.

---

3-1. TCP 에서는 패킷의 순서를 어떻게 보장하나요?

패킷의 헤더에 포함되어있는 Sequence Number를 수신측에서 참조하여 패킷들의 순서를 맞추게 됩니다.

---

4. HTTP 와 HTTPS 의 차이에 대해 설명해보세요.

1. HTTPS는 HTTP 프로토콜에 SSL/TLS 인증이 적용된 버전입니다. 보안 인증서를 사용하기 때문에 평문으로 전송되는 HTTP와 달리, 모든 데이터가 암호화 되어 날아갑니다.

2. HTTPS는 일반적으로 443 포트를 사용합니다. 3-way Handshake 과정 이후에 클라이언트가 ACK만을 보내는 것이 아니라, 별도의 암호화 협상 패킷을 함께 보내는 것으로 SSL Handshake 과정이 시작됩니다.

---

4-1. Well-Known Port가 무슨 뜻인가요?

특정한 쓰임새를 위해서 IANA에서 할당한 TCP 및 UDP 포트 번호의 일부입니다. 0번부터 1023번 까지의 포트를 가리키고, 그 중 보편적으로 쓰이는 것들이 있습니다.

 

20, 21 : FTP 관련

22 : SSH

23 : TELNET

25 : SMTP

53 : DNS

67, 68 : DHCP 관련

80 : HTTP

110 : 단순 POP3

139 : NETBIOS

143 : 단순 IMAP4

443 : HTTPS

445 : SMB

993 : SSL + IMAP4

995 : SSL + POP3

---

5. HTTP 메소드에는 무엇이 있고, 어떤 역할을 하는지 설명해보세요.

1. 주로 GET, POST, PUT, PATCH, DELETE가 있고 HEAD, OPTIONS, CONNECT 도 있긴 한데 주로 앞의 5개를 사용합니다.

2. GET은 리소스를 조회하려고 할 때 사용하고, 필요한 데이터들이 URL 쿼리스트링 형태로 담겨집니다. 따라서 보안에 취약합니다.

3. POST는 리소스를 추가하거나, 서버에서 정의한 다양한 작업을 수행할 때 사용합니다. 리소스의 URI를 모르는 상태에서 새로운 리소스를 생성할 수 있습니다.

4. PATCH는 리소스를 업데이트 할 때 사용합니다. 그러기 위해서는  리소스의 URI를 정확히 알고 있어야 하고, 수정 요청을 한 부분만 수정됩니다.

5. PUT도 리소스를 업데이트할 때 사용합니다. 마찬가지로 리소스의 URI를 정확히 알고 있어야 하고,  PATCH와 다른 점은 리소스의 전체가 업데이트됩니다. 즉, 리소스의 일부만 수정하고 싶어도 나머지 필드 데이터도 포함해서 보내야 합니다. 그리고 이러한 덮어쓰기 성질 때문에 리소스가 서버에 없는 경우 새롭게 생성되어 대체되는 성질이 있습니다.

6. DELETE는 리소스를 제거할 때 사용하며, 멱등성을 지닙니다.

---

5-1. 멱등성이란 무엇인가요?

1. 동일한 연산을 반복해도 결과가 달라지지 않는 특성입니다. POST 메서드의 경우 멱등성이 없기 때문에, 서버에 무한히 요청할 경우 무한한 리소스가 생성됩니다.

2. 따라서 멱등성을 보장하는 요청 즉, 멱등한 요청은 네트워크가 불안정하여 동일한 요청을 여러 번 보내야 하는 경우, 처리의 부작용을 방지하는 성질이라고 할 수 있습니다.

---

5-2. 조회 요청에서 POST 대신 GET을 사용하는 이유가 있나요?

POST로도 조회가 가능하지만 POST 메서드는 멱등성을 지니지 않습니다. 따라서 여러 번 수행했을 때 같은 동작을 하리라는 보장이 없습니다. 또한 POST에 비해 GET은 캐싱을 이용하므로, 조회 속도면에서 우수합니다.

---

5-3. RESTful API에 대해 아는 만큼 설명해보세요.

1. RESTful 하다는 것은 어떤 서비스 아키텍처를 REST 원칙을 잘 지켜 만들었다는 의미이고, REST는 Representation State Transfer의 약자입니다.

2. 기존 방식이 사이트의 특정 URI에 접근 할 때마다 어떤 동작을 취하는 메서드를 호출해서, 그 응답을 클라이언트에게 알려주는 정도였다면, 이제는 URI에서 특정 대상을 명사형으로 호출하고 그 대상에 대해서 GET, POST, PUT, PATCH, DELETE라는 행위를 가함으로써, 기존의 DB에 가해졌던 CRUD 행위를 자연스럽게 매핑하는 방식이 RESTful 방식입니다.

3. 설계 규칙은 다음과 같습니다.

- URI에 밑줄 대신 하이픈 사용.

- URI 경로에는 소문자 사용.

- URI에는 파일 확장자를 넣지 않음.

- 계층 관계 표현시 URL 마지막에 슬래시를 넣지 않음.

- 조회 작업시 쿼리스트링을 활용.

- HTTP 메서드 및 응답 코드를 용도에 맞게 정확히 사용.

---

5-4. RESTful 한 아키텍처의 장점과 단점을 설명해보세요.

장점 : 

1. REST 아키텍처는 HTTP이라는 범용적인 프로토콜 기반이므로, 다양한 환경에서 구현하기가 상대적으로 쉽습니다.

2. 무상태성을 띄기 때문에 스케일 아웃 방식의 확장에 유리합니다.

3. 캐싱 기능을 그대로 사용할 수 있기 때문에 서버 부하를 줄일 수 있습니다.

4. 잘 구현된 REST API의 경우, 명사와 그에 대한 동작이 자연스럽게 매핑되었기 때문에 API 문서 없이도 요청을 보내고 응답을 해석하는 것이 비교적 쉽습니다.

5. 클라이언트와 서버가 분리되어있기 때문에, 한쪽의 변경이 다른 쪽에 큰 영향을 미치지 않습니다.

단점 : 

1. 무상태성을 띄기 때문에 요청마다 인증 등의 정보를 보내야 할 수 있습니다.

2. 새로운 버전의 API를 출시할 때 호환성 유지를 위한 작업이 필요할 수 있습니다.

3. 세세한 정보를 가져오기 어렵기 때문에 클라이언트가 여러 번 요청해야 할 수 있습니다.

---

5-5. HTTP 상태 코드에 대해 아는 만큼 설명해보세요.

1XX 계열은 요청이 수신되어 처리중이라는 의미입니다. 잘 사용되지 않습니다.

2XX 계열은 요청이 성공적으로 처리되었다는 의미를 가집니다. `200 OK` 및 `201 Created`가 주로 사용됩니다.

3XX 계열은 리다이렉션을 의미합니다. 어떤 요청이 성공하려면 추가적인 작업이 필요함을 의미합니다.

4XX 계열은 클라이언트 측이 잘못된 요청을 했다는 의미입니다. `400 Bad Request`, `401 Unauthorized`, `403 Forbidden`, `404 Not Found` 등이 주로 사용합니다.

5XX 계열은 서버측이 잘못된 처리를 했다는 의미입니다. 주로 `500 Internal Server Error` 가 사용됩니다.

---

5-6. SSR과 CSR의 차이에 대해 아는 만큼 설명해보세요.

1. SSR 방식은 서버에서 렌더링하여 클라이언트에게 전달하는 방식입니다. 문서가 클라이언트에 도착하면 HTML은 CSS, JS를 다운로드합니다. CSS, JS가 다운로드 되고 적용되는동안 사용자는 HTML 페이지를 볼 수 있습니다.

CSR 방식은 서버에서 클라이언트에 렌더링에 필요한 파일들을 보내줍니다. 예를 들어 크롬의 경우 크롬 엔진이 파일들을 받고, JS 다운로드가 완료된 시점부터 렌더링을 시작하고, 그 전까지 문서가 다운로드되는 동안은 클라이언트 측에서 아무 것도 볼 수 없습니다.

2. 각 방식의 차이로, 페이지 로딩 시간의 차이가 있습니다. SSR의 경우 페이지를 이동하게 되면, 이동할 페이지를 서버에서 렌더링하여 클라이언트에 보내기 때문에 상대적으로 느립니다. 반면 CSR은 경우에 따라 로딩 자체는 SSR보다 빠를 수 있습니다. 만약 SPA 방식의 서비스라면, 이동할 페이지의 같은 부분은 이미 렌더링이 끝난 상태이고, 나머지 새로운 부분만 클라이언트 측에서 렌더링되기 때문에 SSR보다 상대적으로 빠를 수 있습니다.

3. 검색 엔진에는 SSR 방식이 유리합니다. SSR은 서버에서 HTML이 렌더링되어 클라이언트로 넘어오기 때문에 HTML 구조가 크롤러에 필터링 될 수 있지만, CSR은 렌더링 과정을 클라이언트 측에서 진행해야 하기 때문에 필터링 되지 않습니다.