기술 면접 - 네트워크

1. 웹 동작 방식

---

브라우저 주소창에 http://www.test.com 입력 후 엔터를 눌렀을 때 부터 페이지가 렌더링되는 과정

1. local DNS 서버에게 www.test.com에 해당하는 ip주소가 있는지 물어본다. 있다면 바로 해당 ip로 받아온다.
2. local DNS 서버에 없다면 루트 DNS 서버에 물어본다. 있다면 바로 해당 ip로 받아온다.
3. 루트 DNS 서버에 없다면 .com 을 관리하는 DNS 서버에 물어본다. 있다면 바로 해당 ip를 받아온다.
4. .com 을 관리하는 DNS 서버에 없다면, test.com을 관리하는 DNS 서버에 물어본다. 있다면 바로 해당 ip를 받아온다.
5. 목적지의 ip를 알게되었으니 TCP 통신을 통해 소켓을 개방한다.
6. HTTP 프로토콜로 요청한다.
7. 만약 라우팅 중 프록시 서버를 만난다면 웹 캐시에 저장된 정보를 response 받는다.
8. 프록시 서버를 만나지 못해 www.test.com을 서빙하는 서버까지 간다면 서버에서 요청에 맞는 데이터를 response로 전송한다.
9. 브라우져의 loader가 해당 response를 다운로드할지 말지 결정을한다.
10. 브라우져의 웹 엔진이 다운로드한 .html 파일 렌더링

OSI 7 계층과 연관지은 것

브라우저가 URL에 적힌 값을 파싱해서 HTTP Request Message를 만들고, OS에 전송 요청을 합니다. 이 때, Domain으로 요청을 보낼 수 없기 때문에 DNS Lookup을 수행합니다.

DNS 룩업 과정은 크롬의 경우 브라우저 → hosts 파일 → DNS Cache의 순서로 도메인에 매칭되는 ip를 찾습니다. 일반적으로 설명하는 DNS Lookup은 루트 도메인서버에서부터 서브도메인 서버순으로 찾게됩니다.

이 요청은 프로토콜 스택이라는 OS에 내장된 네트워크 제어용 소프트웨어에 의해 패킷에 담기고 패킷에 제어정보를 덧붙여 LAN 어댑터에 전송하고, LAN 어댑터는 이를 전기신호로 변환시켜 송출합니다.

패킷은 스위칭 허브 등을 경유하여 인터넷 접속용 라우터에서 ISP로 전달되고 인터넷으로 이동합니다.
액세스 회선에 의해 통신사용 라우터로 운반되고 인터넷의 핵심부로 전달됩니다. 고속 라우터들 사이로 목적지까지 패킷이 흘러들어가게 됩니다.

핵심부를 통과한 패킷은 목적지의 LAN에 도착하고, 방화벽이 패킷을 검사한 후 캐시 서버로 보내어 웹 서버에 갈 필요가 있는지 검사합니다.

웹 서버에 도착한 패킷은 프로토콜 스택이 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘깁니다. 애플리케이션은 요청에 대한 응답 데이터를 작성하여 클라이언트로 회송하고, 이는 전달된 방식 그대로 전송됩니다.

2. TCP / UDP 차이

---

TCP는 연결형 서비스로 3-way handshaking 과정을 통해 연결을 설정합니다. 그렇기 때문에 높은 신뢰성을 보장하지만 속도가 비교적 느리다는 단점이 있습니다. UDP는 비연결형 서비스로 3-way handshaking을 사용하지 않기 때문에 신뢰성이 떨어지는 단점이 있습니다. 하지만 수신 여부를 확인하지 않기 때문에 속도가 빠릅니다. TCP는 신뢰성이 중요한 파일 교환과 같은 경우에 쓰이고 UDP는 실시간성이 중요한 스트리밍에 자주 사용됩니다.

3. TCP 3-way, 4-way handshaking

---

3-way

	Client 상태	전송 데이터	Server 상태
1	CLOSE	# 연결 X	LISTEN
2	CLOSE	--SYN->	LISTEN
3	CLOSE		SYN_RCV
4	CLOSE	<-ACK+SYN--	SYN_RCV
5	ESTABLISHED	--ACK->	SYN_RCV
6	ESTABLISHED	# 연결 성공	ESTABLISHED

4-way

	Client 상태	전송 데이터	Server 상태	전송 데이터	애플리케이션 상태
1	ESTABLISHED	# 연결 중	ESTABLISHED		# 프로세스 진행
2	FIN_WAIT_1	--FIN->	ESTABLISHED		-
3	FIN_WAIT_1	<-ACK--	CLOSE_WAIT		-
4	FIN_WAIT_2		CLOSE_WAIT	--CLOSE()->	# 프로세스 종료
5	FIN_WAIT_2	<-FIN--	LAST_ACK
6	TIME_WAIT	--ACK->	LAST_ACK
7	CLOSED	# 연결 X	CLOSED

4-way / 서버가 마지막에 FIN을 보내는 이유?

서버가 아직 클라이언트에 보낼 데이터가 남아있을 경우 데이터를 다 전송하지도 못한 채 클라이언트 에서 포트를 닫아버리게 되므로 서버 또한 종료될 준비가 되었다는 의미로 FIN을 보냄

4-H / 클라이언트가 마지막에 ACK를 굳이 보내는 이유?

서버가 보낸 FIN을 클라이언트가 받지 못하면 클라이언트는 FIN_WAIT_2 상태로 종료가 되지 못한 채 계속 기다려야 한다. 하지만 서버는 이미 포트를 닫고 더는 응답을 하지 않는 상태이기에 클라이 언트는 불필요한 자원을 소모할 수 있음

4. OSI 7 계층

---

ISO(국제표준화기구)에서 네트워크 통신 과정을 7단계로 정의한 국제통신표준규약

• Physical : 전송하는데 필요한 기능 제공 (통신 케이블, 허브)
• Data Link : 송/수신 확인, MAC Address로 통신 (브릿지, 스위치)
• Network : IP를 기반으로 데이터(패킷) 전송 경로 결정 (라우팅)
• Transport : TCP/UDP 포트 정보를 참조해 데이터의 전송
• Session : 통신 시스템 사용자 간의 연결을 유지 및 설정
• Presentation : 세션 계층 간의 주고받는 인터페이스를 일관성 있게 제공
• Application : 사용자가 네트워크에 접근할 수 있도록 서비스를 제공

5. ARP, RARP

---

	ARP	RARP
공통점	-네트워크 계층에서 사용되는 주소 결정 프로토콜
차이점	IP 주소에서 MAC 주소를 알아냄	MAC 주소에서 IP 주소를 알아냄

• 상대방 MAC 주소를 모를 때, IP와 브로드 캐스팅 네트워크 주소 FFFFFFFFFFFF를 가지는 ARP 패킷을 네트워크에 전송하여 이를 수신한 호스트가 자신의 MAC 주소를 반송하는 메커니즘

6. 로드 밸런서

---

로드밸런서는 서버에 가해지는 부하(=로드)를 분산(=밸런싱)해주는 장치 또는 기술을 통칭합니다. 클라이언트와 서버풀(Server Pool, 분산 네트워크를 구성하는 서버들의 그룹) 사이에 위치하며, 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 퍼포먼스를 보일 수 있도록 합니다.

Scale-up의 경우 서버 자체의 성능을 확장하는 것을 의미합니다. 비유하자면 CPU가 i3인 컴퓨터를 i7으로 업그레이드하는 것과 같습니다. 반면 Scale-out의 경우 기존 서버와 동일하거나 낮은 성능의 서버를 두 대 이상 증설하여 운영하는 것을 의미합니다. CPU가 i3인 컴퓨터를 여러 대 추가 구입해 운영하 것에 비유할 수 있습니다.
Scale-out의 방식으로 서버를 증설하기로 결정했다면 여러 대의 서버로 트래픽을 균등하게 분산해주는 로드밸런싱이 반드시 필요합니다.

7. 주요 프로토콜 포트

---

프로토콜	포트 번호	내용
HTTP	80	웹을 지원하기 위한 프로토콜. GET, PUT 같은 프로토콜 기능을 포함해서 웹 서버에게 어떠한 Content를 요청하고 또는 웹 서버로 정보를 보냄
FTP	20, 21	TCP를 활용해 대량의 파일을 송신하고 수신하는 프로토콜
TFTP	69	UDP를 사용하는 파일 전송 프로토콜, 라우터나 스위치 등의 네트워크 장 비의 IOS 이미지를 업로드, 다운로드할 때 사용
Telenet	23	원격지에 있는 장비로 표준 터미널 에뮬레이션 기능을 제공함. 네트워크 장비에서는 텔넷을 통해 원격지에서 장비를 설정
SMTP	25	컴퓨터 네트워크를 통해 전자 메일을 전송하는 프로토콜. 받을 때는 POP3 를 활용
SNMP	161	네트워크 장비를 모니터링하고 제어하기 위해 사용하는 프로토콜로 네트워 크 장애 관리, 장비 설정, 통계 성능 및 보안 등을 관리
DNS	53	도메인 주소를 IP ADDRESS로 변경, 모든 퍼블릭 IP 주소와 호스트 이름 은 DNS에 저장되고 나중에 해당 IP 주소로 변환

8. HTTP, HTTPS

---

HTTP

HTTP(Hyper Text Transfer Protocal)이란 서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜입니다. HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동합니다. HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성됩니다.

HTTPS

HTTP + SSL, HTTP로 통신하는 소켓을 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 프로토콜로 대체한 것 (새로운 별개의 프로토콜이 아니라 연결 방식이 달라진 것)

• HTTP는 TCP와 직접 통신하지만, HTTPS에서는 SSL과 통신하고 SSL이 TCP와 통신하는 방식

• SSL을 사용하기 때문에 암호화와 증명서, 안전성 보호를 이용할 수 있음

• 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템 사용, 공통키를 공개 키 암호화 방식으로 교환하고 이후 통신은 공통키 암호를 사용하는 방식

8. HTTP REQUEST - GET, POST

---

GET

우선 GET 방식은 요청하는 데이터가 HTTP Request Message의 Header 부분에 url 이 담겨서 전송된다. 때문에 url 상에 ? 뒤에 데이터가 붙어 request 를 보내게 되는 것이다. 이러한 방식은 url 이라는 공간에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적이다. 또 보안이 필요한 데이터에 대해서는 데이터가 그대로 url 에 노출되므로 GET방식은 적절하지 않다. (ex. password)

POST

POST 방식의 request 는 HTTP Request Message의 Body 부분에 데이터가 담겨서 전송된다. 때문에 바이너리 데이터를 요청하는 경우 POST 방식으로 보내야 하는 것처럼 데이터 크기가 GET 방식보다 크고 보안면에서 낫다.(하지만 보안적인 측면에서는 암호화를 하지 않는 이상 고만고만하다.)

그렇다면 이러한 특성을 이해한 뒤에는 어디에 적용되는지를 알아봐야 그 차이를 극명하게 이해할 수 있다. 우선 GET 은 가져오는 것이다. 서버에서 어떤 데이터를 가져와서 보여준다거나 하는 용도이지 서버의 값이나 상태 등을 변경하지 않는다. SELECT 적인 성향을 갖고 있다고 볼 수 있는 것이다. 반면에 POST 는 서버의 값이나 상태를 변경하기 위해서 또는 추가하기 위해서 사용된다.

부수적인 차이점을 좀 더 살펴보자면 GET 방식의 요청은 브라우저에서 Caching 할 수 있다. 때문에 POST 방식으로 요청해야 할 것을 보내는 데이터의 크기가 작고 보안적인 문제가 없다는 이유로 GET 방식으로 요청한다면 기존에 caching 되었던 데이터가 응답될 가능성이 존재한다. 때문에 목적에 맞는 기술을 사용해야 하는 것이다.