네트워크
[https://www.naver.com을 접속했을 때 발생하는 일]
브라우저가 URL에 적힌 값을 파싱해서 HTTP Request Message를 만들고, OS에 전송 요청을 한다. 이 때, 도메인으로 요청을 보낼 수 없기 때문에 DNS Lookup을 수행한다.
DNS Lookup은 브라우저 => hosts파일 => DNS Cache의 순서로 도메인에 매칭되는 IP를 찾는다. 일반적으로 루트 도메인 서버에서부터 서브 도메인 서버순으로 찾게 된다.
이 요청은 프로토콜 스택이라는 OS에 내장된 네트워크 제어용 소프트웨어에의해 패킷에 담기고 패킷에 제어정보를 덧붙여 LAN어댑터에 전송하고, LAN어댑터는 이를 전기신호로 변환시켜 송출한다.
패킷은 스위칭 허브등을 경유하여 인터넷 접속용 라우터에서 ISP로 전달되고 인터넷으로 이동한다. 액세스 회선에 의해 통신사용 라우터로 운반되고 인터넷의 핵심부로 전달된다. 고속 라우터들 사이로 목적지까지 패킷이 흘러들어가게된다.
핵심부를 통과한 패킷은 목적지의 LAN에 도착하고, 방화벽이 패킷을 검사한 후 캐시 서버로 보내어 웹 서버에 갈 필요가 있는지 검사한다.
웹 서버에 도착한 패킷은 프로토콜 스택이 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘긴다. 애플리케이션은 요청에 대한 응답 데이터를 작성하여 클라이언트로 회송하고, 이는 전달된 방식 그대로 전송된다.
[TCP와 UDP의 차이점]
TCP는 연결 지향형 프로토콜이고 UDP는 데이터를 데이터그램단위로 전송하는 프로토콜이다.
TCP는 가상 회선을 만들어 신뢰성(흐름 제어, 혼잡 제어, 오류 제어)을 보장하도록 하는 프로토콜로 따로 신뢰성을 보장하기 위한 절차가 없는 UDP에 비해 속도가 느리다.
TCP는 신뢰성이 있는 전송방식이기 때문에, 파일전송과 같은 신뢰성이 중요한 서비스에 사용되고 UDP는 스트리밍, RTP와 같이 연속성이 더 중요한 서비스에 사용된다.
[TCP 3way handshake]
TCP 3way handshake는 가상회선을 수립하는 단계이다. 클라이언트는 서버에 요청을 전송할 수 있는지 서버는 클라이언트에게 응답을 전송할 수 있는지 확인하는 과정이다. SYN, ACK패킷을 주고받으며 임의의 난수로 SYN플래그를 전송하고 ACK플래그에는 1을 더한 값을 전송한다. 임의의 난수로 지정하는 이유는 기존 요청과 구분하기 위함이다.
[TCP 4way handshake]
TCP 4way handshake는 TCP연결을 해제하는 단계로, 클라이언트는 서버에게 연결해제를 통지하고 서버가 이를 확인하고 클라이언트에게 이를 받았음을 전송해주고 최종적으로 연결이 해제된다. 단, 서버에서 소켓이 닫혔다고 통지해도 클라이언트 측에서는 일정시간 대기하는데 혹시나 패킷이 나중에 도착할 수 있기 때문이다.
[HTTP vs HTTPS]
HTTP는 따로 암호화 과정을 거치지 않기 때문에 중간에 패킷을 가로챌 수 있고, 수정할 수 있다. 따라서 보안이 취약해짐을 알 수 있다. 이를 보완하기 위해 나온 것이 HTTPS이다. HTTPS는 중간에 암호화 계층을 거쳐서 패킷을 암호화한다.
[HTTPS에 대해서 설명하고 SSL handshake]
HTTPS는 HTTP에 보안 계층을 추가한 것이다. HTTPS는 제3자 인증, 공개키 암호화, 비밀키 암호화를 사용한다.
제3자 인증은 믿을 수 있는 인증기관에 등록된 인증서만 신뢰하는 것이고, 공개키 암호화는 비밀키를 공유하기위해 사용한다. 비밀키 암호화는 통신하는 데이터를 암호화하는데 사용한다.
클라이언트는 TCP 3way handshake를 수행한 이후 Client Hello를 전송한다. 서버는 인증서를 보낸다. 클라이언트는 받은 인증서를 신뢰하기 위해 등록된 인증기관인지 확인한다. 이 인증서는 인증기관의 개인키로 암호화되어있고, 공개키로 검증할 수 있다. 클라이언트는 사이트의 정보와, 서버의 공개키를 얻을 수 있다.
서버의 공개키로 통신에 사용할 비밀키를 암호화해서 서버에 보낸다. 서버는 이를 개인키로 확인하고 이후 통신은 공유된 비밀키로 암호화되어 통신한다.
- 제3자 인증: 인증서, 인증기관
- 공개키 암호화: 인증서, 비밀키 공유
- 비밀키 암호화: 통신과정
[GET과 POST의 차이점에 대한 설명]
GET은 서버에 존재하는 정보를 요청한다. 이 때 반환되는 정보는 정보자체가 아닌 정보의 표현이다.
POST는 서버에 정보를 생성하는 것을 요청한다. 예전 HTTP통신은 POST요청으로 데이터 수정, 삭제도 form요청으로 같이 수행했다. POST요청은 서버의 상태를 변경시키기 때문에 멱등성이 유지되지 않는다. 보통 Request Body에 요청하는 데이터를 담아 전송한다.
[HTTP 메서드와 역할]
- GET요청은 서버에 존재하는 데이터를 요청하는 것이다.
- POST요청은 서버에 데이터를 생성하는 것을 요청하는 것이다.
- PUT요청은 서버에 존재하는 데이터를 수정하거나 존재하지 않으면 생성한다.
- DELETE요청은 서버에 데이터를 제거할 것을 요청한다. 존재하지 않아도 동일하게 동작한다.
- PATCH요청은 서버에 존재하는 데이터를 일부 수정한다.
[RESTful이란?]
HTTP URI를 통해 자원을 표시하고 HTTP Method를 통해 자원에 대한 처리를 표현한다. 사람이 읽을 수 있는 API라는 것이 특징이다. HTTP를 사용하기 때문에 HTTP의 특성을 그대로 반영한다. 또한 별도의 인프라 구축이 필요 없다.
단점으로는 명확한 표준이 존재하지 않는다는 점, RESTful을 완전히 만족하는 API를 만들기 까다롭다는 점, REST API가 분산환경에 적합하지 않다는 점이 있다.
[CORS란?]
CORS는 웹 개발을 하다 만날 수 있는 이슈로 프론트엔드 개발시에 로컬에서 API서버에 요청을 보낼 때 흔하게 발생한다.
이는 서로 다른 도메인간에 자원을 공유하는 것을 의미한다. 대부분의 브라우저에서는 이를 기본적으로 차단하며 서버측에서 헤더를 통해 사용가능한 자원을 알려준다.
preflight request는 실제 요청을 보내도 안전한지 판단하기 위해 사전에 보내는 요청이다. OPTIONS메서드로 요청하며 CORS를 허용하는지 확인한다. CORS가 허용된 웹 서버라면 사용 가능한 리소스를 헤더에 담아 응답한다.
[OSI 7계층과 TCP/IP 4계층]
OSI 7계층은 네트워크 통신을 구성하는 요소들 7개의 계층으로 표준화한 것이다. 이렇게 표준화하는 것의 장점은 통신이 일어나는 과정을 단계별로 파악할 수 있어, 문제가 발생하면 해당 문제를 해결하기 용이해진다.
실제로 우리가 대부분 사용하는 네트워크는 TCP/IP 4계층이다. 통신에 실제로 사용되는 계층이고 1,2계층이 1계층, 5,6,7계층이 4계층으로 운영된다.
