10/02 면접 준비 + 변경 내용

게시 2023/10/02

By Jeremiah Lee 21 분 : 읽는 시간

취업 준비 카테고리를 변경하고자 한다. 코테 준비 집합 같은 경우는 애초에 해당 스터디를 진행한 후에 코테 카테고리의 프로그래머스 란에 작성하기 때문에 이 카테고리에 추가할 필요가 없다고 느꼈다. 느낀점을 쓰는 것도 사실 코테 카테고리에 정리할 때 한 두줄 정도 같이 쓰기 때문에 중복된다고 생각한다. 또한 면접 준비 같은 경우도 진행 방식에 변경 사항이 있다. 이전과 같이 당일 진행한 내용을 정리해서 쓰지 않고 스터디 하고자 하는 내용을 미리 정리한 다음 그것을 토대로 면접 준비 스터디를 진행하려고 한다. 그렇기 때문에 면접 스터디를 한 당일은 다음 날짜와 다음 내용을 정리할 것이다.

변경 사항을 정리하면 아래와 같다.

취업 준비 카테고리 내의 코테 준비 정리 중단
동일 카테고리 내의 면접 준비는 진행하되 당일에 다음 내용 정리

CS 관련 지식

네트워크

1. 웹 통신의 큰 흐름

브라우저가 URL에 적힌 값을 파싱해서 HTTP 리퀘스트 메시지를 만들고, OS가 TCP 프로토콜을 사용하여 인터넷을 통해 해당 IP 주소의 웹 서버로 전송하도록 합니다.
이 때, DNS 서버에서 도메인 네임에 해당하는 IP 주소를 찾는 DNS Lookup을 수행합니다.
DNS 룩업은 브라우저 -> hosts 파일 -> DNS Cache의 과정으로 도메인에 매칭되는 IP를 찾습니다.
이 요청은 프로토콜 스택에 의해 패킷에 담기고 패킷에 제어 정보를 덧붙여 LAN 어댑터에 전송합니다.
그리고 LAN 어댑터는 이를 전기 신호로 변환시켜 송출합니다.
패킷은 스위칭 허브 등을 경유하여 인터넷 접속용 라우터에서 ISP로 전달되고 인터넷으로 이동합니다.
액세스 회선에 의해 통신사용 라우터로 운반되고 인터넷의 핵심부로 전달됩니다.
고속 라우터들 사이로 패킷이 목적지의 LAN에 도착하면, 방화벽이 패킷을 검사한 후 캐시 서버로 보내어 웹 서버에 갈 필요가 있는지 검사합니다.
웹 서버에 도착한 패킷은 목적지의 LAN에 도착하면, 방화벽이 패킷을 검사한 후 캐시 서버로 보내어 웹 서버에 갈 필요가 있는지 검사합니다.
이렇게 도착한 HTTP 리퀘스트 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 URL 정보로 변환되고, 웹 페이지 URL 정보에 해당하는 데이터를 검색합니다.
검색된 웹 페이지 데이터는 다시 HTTP 프로토콜을 사용하여 HTTP 리스폰스 메시지를 생성하고 전달된 방식 그대로 TCP 프로토콜을 사용하여 인터넷을 거쳐 웹 클라이언트로 전송됩니다.

2. TCP와 UDP의 차이점

TCP는 연결 지향형 프로토콜이고 UDP는 데이터를 데이터그램 단위로 전송하는 프로토콜입니다.
TCP는 가상 회선을 만들어 신뢰성을 보장하도록 하는 프로토콜로 따로 신뢰성을 보장하기 위한 절차가 없는 UDP에 비해 속도가 느립니다.
그렇기 때문에 TCP는 파일 전송과 같은 신뢰가 중요한 서비스에 사용되고, UDP는 스트리밍, RTP와 같이 연속성이 더 중요한 서비스에 사용됩니다.
하지만 UDP도 신뢰성을 UDP 자체에서 보장하지 않는 것 뿐이고, 개발자가 직접 신뢰성을 보장할 수 있도록 할 수 있습니다. 그래서 HTTP/3는 QUIC라는 프로토콜을 기반으로 하는데, QUIC는 UDP를 기반으로 합니다. 즉, UDP 자체는 신뢰성을 보장하지 않지만, 추가적인 정의를 통해 신뢰성을 보장받을 수 있습니다.

3. TCP 3, 4 way-handshake

TCP 3 way-handshake는 가상회선을 수립하는 단계입니다. 클라이언트는 서버에 요청을 전송할 수 있는지, 서버는 클라이언트에게 응답을 전송할 수 있는지를 확인하는 과정입니다.
Synchronize Sequence Number, Acknowledgement 패킷을 주고 받으며, 임의의 난수로 SYN 플래그를 전송하고, ACK 플래그에는 1을 더 한 값을 전송합니다.
여기서 임의의 난수로 지정하는 이유는 TCP 커넥션을 맺을 때 사용하는 포트는 유한 범위에서 사용되고 시간이 지나면 재사용됩니다. 이는 두 통신 주체가 과거에 사용되었던 포트 번호를 쌍으로 이용할 수 있는 가능성이 있다는 것이므로 과거의 중복된 패킷을 피하기 위해 난수로 설정하는 것 입니다.
TCP 4 way-handshake는 TCP 연결을 해제하는 단계로 클라이언트는 서버에게 연결 해제를 통지하고 서버가 이를 확인하고 클라이언트에게 통지 받았음을 전송하고 최종적으로 연결이 해제됩니다. 단, 서버에서 소켓이 닫혔다고 통지해도 클라이언트 측에서는 일정시간 대기하는데, 혹시나 패킷이 나중에 도착할 수 있기 때문입니다.

4. HTTP와 HTTPS의 차이

클라이언트와 서버 간 통신을 위한 통신 규칙 세트 또는 프로토콜인 HTTP는 따로 암호화 과정을 거치지 않기 때문에 중간에 패킷을 가로챌 수 있고, 수정 등 데이터가 변질될 수 있습니다. 따라서 보안이 취약해질 수 있습니다. 이를 보완하기 위해 나온 것이 HTTPS입니다. 데이터 전송 중간에 통신 자체를 암호화하는 Secure Sockets Layer 프로토콜을 조합하여 HTTP 통신 내용을 암호화하는 것이 HTTPS입니다.

5. HTTPS와 SSL hand-shake

HTTPS는 HTTP에 보안 계층을 추가한 것입니다. HTTPS는 제 3자 인증, 공개키 암호화, 비밀키 암호화를 사용합니다.
제 3자 인증은 믿을 수 있는 인증기관에 등록된 인증서만 신뢰하는 것이고, 공개키 암호화는 비밀키를 공유하기 위해 사용합니다. 비밀키 암호화는 통신하는 데이터를 암호화하는데 사용합니다.
클라이언트는 TCP 3 way-handshake를 수행한 이후 Client Hello를 전송합니다. 이 다음 서버는 인증서를 보냅니다.
클라이언트는 받은 인증서를 신뢰하기 위해 등록된 인증기관인지 확인합니다. 이 인증서는 인증기관의 개인키로 암호화되어 있고, 공개키로 검증할 수 있습니다.
클라이언트는 사이트의 정보와 서버의 공개키를 얻을 수 있습니다.
서버의 공개키로 통신에 사용할 비밀키를 암호화해서 서버에 보냅니다. 서버는 이를 개인키로 확인하고 이후 통신은 공유된 비밀키로 암호화되어 통신합니다.
여기서 공개키와 비밀키를 복합적으로 사용하는 이유는 대칭키는 암호와 복호의 키가 같아 암호하는 연산이 간단하고 빠르지만 대칭키가 탈취되면 암호가 쉽게 노출되는 단점이 있습니다. 반면 공개키는 암호와 복호 키가 서로 달라 암호 연산이 느리지만 공개키를 뺏겨도 암호를 풀 수 없기 때문에 보안이 강하다는 장점을 가지고 있습니다. 그렇기 때문에 공개키와 대칭키의 장점을 모두 취하기 위해 SSL은 두 가지를 혼용해서 사용합니다.

6. GET과 POST의 차이

GET 요청은 서버에 존재하는 정보를 요청합니다. 이 때 반환되는 정보는 정보 자체가 아니라 정보의 표현입니다.
Request Body는 입력하지 않는 것이 일반적이며, 레거시 시스템의 경우 요청을 받아들이지 않을 수 있습니다.
캐싱을 수행하기 때문에 캐싱되지 않은 요청은 GET 요청이 맞지 않을 수 있습니다.
POST 요청은 서버에 정보를 생성하는 것을 요청합니다.
예전 HTTP 통신은 POST 요청으로도 데이터 삭제, 수정을 할 수 있었습니다.
POST 요청은 서버의 상태를 변경시키기 때문에 멱등성이 유지되지 않습니다. 보통 Request Body에 요청하는 데이터를 담아 전송합니다.
여기서 멱등성이란 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 뜻하며 보통 GET, PUT, DELETE 메서드의 성질로 볼 수 있습니다.

7. HTTP 메서드

주로 GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD 가 있습니다.
GET 요청은 서버에 존재하는 데이터를 요청하는 것입니다.
POST 요청은 서버에 데이터를 생성하는 것을 요청합니다.
PUT 요청은 서버에 존재하는 데이터를 수정하거나 존재하지 않으면 생성합니다.
DELETE 요청은 서버에 데이터를 제거할 것을 요청합니다. 존재하지 않아도 동일하게 동작합니다.
PATCH 요청은 서버에 존재하는 데이터를 일부 수정합니다.
OPTIONS는 해당 uri에 대해 서버가 허용하는 메서드를 확인할 때 사용합니다.
HEAD는 GET과 비슷하나 header만 가져옵니다.
이때 불필요한 메서드는 허용하지 않고 필요한 메서드만 허용하는 whitelist 방식으로 메서드들을 관리해야 합니다. OPTIONS 메서드를 사용하면 서버가 허용하는 메서드를 확인할 수 있는데, 이 때 PUT, DELETE, HEAD와 같은 메서드를 사용하여 공격할 수 있기 때문입니다.

8. RESTful 이란

HTTP URI를 통해 자원을 표시하고 HTTP 메서드를 통해 자원에 대한 CRUD 처리를 표현합니다.
사람이 읽을 수 있는 API라는 것이 특징입니다.
HTTP를 사용하기 떄문에 HTTP의 특성을 그대로 반영합니다.
또한 별도의 인프라 구축이 필요 없습니다.
단점으로는 명확한 표준이 존재하지 않는다는 점과 RESTful을 완전히 만족하는 API를 만들기는 매우 까다롭다는 점이 있습니다.
여기서 HATEOAS라는 개념이 있는데, 모든 관련된 동작을 URI를 통해 알려주기 때문에 동적인 API를 제공할 수 있게 됩니다. 즉, 클라이언트가 API의 변화에 대해 일일이 대응하지 않아도 된다는 장점이 있습니다.

9. CORS란

CORS는 Cross-Origin Resource Sharing으로 서로 다른 도메인 간에 자원을 공유하는 것을 뜻합니다.
대부분의 브라우저에서는 이를 기본적으로 차단하며, 서버 측에서 헤더를 통해 사용 가능한 자원을 알려줍니다.
preflight 요청은 실체 요청을 보내도 안전한지 판단하기 위해 사전에 보내는 요청입니다. OPTIONS 메서드로 요청하며 CORS를 허용하는지를 확인합니다.
이때 CORS가 허용된 웹 서버라면 사용 가능한 리소소를 헤더에 담아 응답합니다.

10. OSI 7계층과 TCP/IP 4계층

OSI 7 계층은 네트워크 통신을 구성하는 요소들을 7개의 계층으로 표준화 한 것입니다.
이렇게 표준화하는 것의 장점은 통신이 일어나는 과정을 단계별로 파악할 수 있어 문제가 발생하면 해당 문제를 해결하기 용이해집니다.
실제로 사용자가 대부분 사용하는 네트워크는 TCP/IP 4 계층입니다. 통신에 실제로 사용되는 계층이고, OSI 1,2 계층이 TCP/IP 1계층, OSI 5, 6, 7 계층이 TCP/IP 4계층으로 운영됩니다.
OSI 7계층은 큰 계층부터 응용 계층, 표현 계층, 세션 계층, 전송 계층, 네트워크 계층, 데이터링크 계층, 물리 계층으로 이루어져 있으며 TCP/IP는 큰 계층부터 응용 계층, 전송 계층, 인터넷 계층, 네트워크 엑세스 계층으로 이루어져 있습니다.

11. 웹 서버 소프트웨어(Apache, Nginx)는 OSI 7 계층 중 어디서 작동하는지

Apache와 Nginx는 HTTP 웹 서버로, 동작하는 HTTP 프로토콜은 OSI 7 계층 중 7번 째 계층인 애플리케이션 계층에 해당하는 프로토콜입니다.
HTTP 프로토콜은 TCP/IP 프로토콜을 통해 동작합니다.
TCP/IP 프로토콜은 OSI 7계층 중 4 계층인 전송 계층에서 동작합니다.
따라서 웹 서버 소프트웨어는 4계층의 TCP/IP 프로토콜과 7계층의 HTTP 프로토콜을 활용하여 동작합니다.

12. OSI 7계층과 TCP/IP 4계층

두 가지가 있습니다.
4계층인 전송 계층과 7 계층인 애플리케이션 계층입니다.
4계층에서는 TCP/UDP 포트 정보를 토대로 라우팅 기능이 제공됩니다.
7계층에서는 TCP/UDP 뿐만 아니라 HTTP의 URI 등을 토대로 라우팅 기능이 제공됩니다.
4 계층에서 라우팅 기능을 사용한 예시를 들면, Nginx의 경우 여러 포트들을 하나의 upstream 블록으로 묶어서 로드 밸런싱, 즉 특정 경로로 전달되는 요청을 각 포트 별로 분산해서 전달하도록 설정 할 수 있습니다.
7 계층에서 라우팅 기능을 사용한 예시를 들면, Apache, Nginx 각각의 서브 도메인에 대해 라우팅 설정을 해 둘 수 있습니다.
브라우저에서 /test와 같은 서브 도메인으로 HTTP 프로토콜을 통한 요청을 보낸다면, 웹서버 내 Config 파일에 설정된 경로 정보를 토대로 요청에 대한 라우팅을 제공하여 스태틱 파일을 전달하거나 API 서버에 대해 리버스 프록시 역할을 해 줄 수 있습니다.

스터디, 면접 스터디

취준 스터디