[CS 기초] Network

OSI 7계층

국제 표준화단체 ISO(International Standard Organiztion)에서 정한 네트워크 연결 시스템이다. HTTP 프로토콜을 이용하여 데이터를 요청하면, 응용 계층부터 위에서 밑으로 차례로 전달된다. 데이터를 받는 과정을 반대로 물리 계층부터 응용 계층으로 올라간다.

위의 그림과 같이 7개의 영역으로 나누어져 있다.
응용계층, 표현계층, 세션계층, 전송계층, 네트워크계층, 데이터링크계층, 물리계층
물데네전세표응

1계층 - 물리계층 (Physical Layer)

이 계층에서는 주로 전기적, 기계적, 기능적인 특성을 이용하여 통신 케이블로 데이터를 전송하게 된다. 이 계층에서 사용되는 통신단위는 비트이며 이것은 1과 0으로 나타내어지는, 즉 전기적으로 On, Off 상태라고 생각하면 된다.
이 계층에서는 단지 데이터를 전달할 뿐, 데이터가 무엇인지, 어떤 에러가 있는지 등은 전혀 신경쓰지 않는다. 단지 데이터를 전기적 신호로 변환해서 주고받는 기능만 할 뿐이다.
이 계층에 속하는 대표적인 장비는 통신 케이블, 리피터, 허브 등이 있다.

2계층 - 데이터링크계층 (Datalink Layer)

물리 계층을 통해 송수신되는 정보의 오류와 흐름을 관리하여 안전한 정보의 전달을 수행할 수 있도록 도와주는 역할을 한다. 따라서 통신에서의 오류를 찾아주고 재전송도 하는 기능을 가지고 있다.
이 계층에서는 맥 주소를 가지고 통신하게 된다. 이 계층에서는 전송하는 단위를 프레임이라 한다. 그리고 물리적 오류를 감지하는 기능을 담당하며, 오류(데이터 분실 or 내용의 파손)를 감지하면 송신자가 원래 데이터를 재전송함으로 일반적으로 처리한다.
대표적인 장비로는 브리지, 스위치 등이 있다.

3계층 - 네트워크계층

송신 호스트가 전송한 데이터가 어떤 경로를 통해 전달되는지 결정하는 라우팅 문제를 다룬다. 네트워크 계층에서의 전송 데이터를 패킷이라 부르며, 네트워크를 이용해 지나치게 많은 패킷이 전송되면, 전송속도가 떨어질 수 있으므로 이를 제어하는 혼잡제어 기능도 담당한다.

라우팅
데이터가 지나갈 경로를 선택해서 이동하는 것을 말함. 즉, 경로 설정

4계층 - 전송계층

전송계층은 송수신 프로세스 간 직접 연결하는 통신기능을 합니다. 전송계층의 하위계층(네트워크계층, 데이터링크계층)은 호스트와 호스트 사이에 데이터 전송과정에서 발생하는 문제들을 다루지만, 전송계층에서는 컴퓨터 내부의 구축되는 통신당사자인 프로세스 사이의 통신문제를 다룬다. 또한, 사용자의 서비스 요구유형에 대한 고려, 전송 오류율, 전송속도 등에 대한 흐름제어 기능도 제공한다.

5계층 - 세션계층

세션계층의 기능은 전송계층과 매우 유사하다. 하지만 사용자가 원격파일로 전송하거나 원격 로그인 등과 같은 상위적 연결 개념인 세션 기능을 제공하는 부분이다. 또한, 송수신 호스트 사이 대화 제어 등의 동작을 제어하기 위한 토큰제어, 일시적 전송장애를 해결하는 동기화 기능을 제공한다.

6계층 - 표현계층

5계층까지는(세션계층 ~ 물리계층) 데이터 전송에 관한 내용을 다루지만 표현계층은 데이터의 의미와 표현방법을 처리한다. 통신 양단에서 서로 이해할 수 있는 표준방식으로 데이터를 코딩하는 문제를 다룬다.

호스트의 데이터 표현방법이 서로 다를 수 있는데, 이러한 데이터를 이해할 수 있도록 적절하게 변환한다. 또, 보안시 중요시 되고 있는 데이터를 암호화하는 기술, 영상 정보같은 대용량의 데이터 크기를 압축하는 기능도 표현계층에서 처리

7계층 - 응용계층

사용자 또는 어플리케이션이 네트워크에 접근할 수 있도록 메일 전송, 인터넷 접속 작업 등을 수행한다.
예를 들면 FTP와 같은 것이 이 계층에 속한다.

TCP/IP 4계층

TCP/IP는 현재의 인터넷에서 컴퓨터들이 서로 정보를 주고 받은데 쓰이는 통신규약(프로토콜)의 모음이다.

1계층 - 네트워크 계층

• OSI 7계층에서 물리계층과 데이터링크 계층에 해당한다.

• OS의 네트워크 카드와 디바이스 드라이버 등과 같이 하드웨어적인 요소와 관련되는 모든 것을 지원하는 계층.

• 송신측 컴퓨터의 경우 상위 계층으로부터 전달받은 패킷에 물리적인 주소는 MAC 주소정보를 가지고 있는 레더를 추가하여 프레임을 만들고, 프레임을 하위계층인 물리계층으로 전달한다.

• 수신측 컴퓨터의 경우 데이터링크 계층에서 추가된 헤더를 제거하여 상위 계층인 네트워크 계층으로 전달한다.

• CSMA/CD, MAC, LAN, X25, 패킷망, 위성통신, 다이얼 모뎀 등 전송에 사용

• 프로토콜: Ethernet(이더넷), Token Ring, PPP

2계층 - 인터넷 계층

• OSI 7계층에서 네트워크 계층에 해당한다.

• 상위 트랜스포트 계층으로부터 받은 데이터에 IP패킷 헤더를 붙여 IP패킷을 만들고 이를 전송하는 것이다.

• 통신 노드간의 IP 패킷을 전송하는 기능 및 라우팅 기능을 담당

• 프로토콜: IP, ARP, RARP, ICMP, OSPF

3계층 - 전송계층

• OSI 7계층에서 전송계층에 해당한다.

• 네트워크 양단의 송수신 호스트 사이에서 신뢰성 있는 전송기능을 제공한다.

• 시스템의 논리주소와 포트를 가지고 있어서 각 상위 계층의 프로세스를 연결해서 통신한다.

• 정확한 패킷의 전송을 보장하는 TCP와 정확한 전송을 보장하지 않는 UDP 프로토콜을 이용한다.

• 데이터의 정확한 전송보다는 빠른 속도의 전송이 필요한 멀티미디어 통신에서 UDP를 사용하면 TCP보다 유용하다.

• 통신 노드 간의 연결을 제어하고, 자료의 송수신을 담당

• 프로토콜: TCP, UDP

4계층 - 응용계층

• OSI 7계층에서 세션계층, 표현계층, 응용계층에 해당한다.

• 응용프로그램들이 네투워크서비스, 메일서비스, 웹서비스 등을 할수 있도록 표준적인 인터페이스를 제공한다.

• TCP/IP 기반의 응용 프로그램을 구분할 때 사용한다.

• 프로토콜: HTTP, FTP, Telnet, DNS, SMTP

OSI 모델과 TCP/IP 모델 비교

• TCP/IP 프로토콜은 OSI보다 먼저 개발되었다. 그러므로 TCP/IP 프로토콜의 계층은 OSI 모델의 계층과 정확하게 일치하지 않는다.
• 두 계층을 비교하면, 세션과 표현 2개의 계층이 TCP/IP 프로토콜 그룹에 없다는 것을 알 수 있다.
• 두 모뎅 모두 계층형이라는 공통점을 가지고 있으며 TCP/IP는 인터넷 개발 이후 계속 표준화되어 신뢰성이 우수한 반면, OSI 7 Layer는 표준이 되기는 하지만 실제적으로 구현되는 예가 거의 없어 신뢰성이 저하되어있다.
• OSI 7 Layer는 장비 개발과 통신 자체를 어떻게 표준으로 잡을지 사용되는 반면, 실질적인 통신 자체는 TCP/IP 프로토콜을 사용한다.

DNS

DNS란, Domain Name System의 약자로서, 사람이 읽을수 있는 도메인 이름(ex. velog.io)을 컴퓨터가 읽을 수 있는 IP주소(ex. 192.168.0.1)로 변환하거나, 반대로 변환하는 시스템.

HTTP / HTTPS

HTTP (HyperTest Transger Protocol)

웹 상에서 서버/클라이언트 모델을 따라 데이터를 주고받기 위한 응용계층 프로토콜로 TCP/IP 위에서 작동한다. HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며, Method, Path, Version, Header, Body 등으로 구성된다.

프로토콜
컴퓨터간 데이터 통신을 원할히 하기 위해 규정한 약속, 신호 송신의 순서(handshaking)나 데이터 표현법, 오류 검출법 등을 정한 것

Cookie / Sesstion
HTTP의 Stateless를 극복하기 위해 사용하는 방식이다.
Cookie에 클라이언트에 대한 정보를 저장해뒀다가 사용하거나 Session을 등록해서 유지하는 방식으로 극복한다.

HTTP의 문제점

• HTTP는 평문 데이터를 전송하는 프로토콜이므로 도청이 가능하다.
• 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
• 완전성을 증명할 수 없기 떄문에 변조가 가능하다.

위 세가지 문제점은 다른 암호화하지 않는 프로토콜에서도 공통되는 문제점들이다.

TCP/IP는 도청 가능한 네트워크이다.

TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것만으로 도청할 수 있다. 평문으로 통신할 경우 메세지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 한다.

보완 방법

1. 통신 차제를 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를 HTTPS(HTTP Secure) or HTTP over SSL이라고 부른다.
2. 콘텐츠를 암호화. 말 그대로 HTTP를 사용해서 운반하는 (통신의 내용에 해당하는) HTTP 메세지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화해서 전송하면, 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.

통신 상대를 확인하지 않기 때문에 위장이 가능하다.

HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리가 없기 떄문에 누구든지 Request를 보낼 수 있다. IP주소나 포트 등에서 그 웹서버에 액세스 제한이 없는 경우 Request가 오면 상대가 누구든지 무언가 Resonse를 반환한다. 이러한 특징은 여러 문제점을 유발한다.

1. Request를 보낸 곳의 웹서버가 원래 의도한 Response를 보내야 하는 웹서버인지 확인할 수 없다.
2. Response를 반환한 곳의 클라이언트가 원래 의도한 Request를 보낸 클라이언트인지 확인할 수 없다.
3. 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다.
4. 어디에서 누가 Request했는지 확인할 수 없다.
5. 의미없는 Request도 수신한다. 따라서 DoS 공격을 방지할 수 없다.

보완 방법

위 암호화 방법으로 언급된 SSL로 상대를 확인할 수 있다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로 써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인정보 누설 등의 위험성이 줄어들게 된다. 한 가지 이점을 더 꼽자면, 클라이언트는 이 증명서로 본인 확인을 하고 웹사이트 인증에서도 이용할 수 있다.

완전성을 증명할 수 없기 때문에 변조가 가능하다.

여기서 완전성이란 정보의 정확성을 의미한다. 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다는 것을 보장할 수없다는 것이다. Reqeust나 Response가 발신된 후에 상대가 수신하는 사이 누군가에 의해 변조되더라도 이 사실을 알 수 없다. 이와 같이 공격자가 도중에 Request나 Response를 빼앗아 변조하는 공경을 중간자 공격(Man-in-the-Middle)이라고 부른다.

보완 방법

MD5, SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 롹인할 수 있는것은 아니다. 확실히 방지하기에는 HTTPS를 사용해야 한다. SSL에는 인증이나 암호화, 다이제스트 기능을 제공하고 있다.

HTTPS (HTTP Secure)

HTTPS는 SSL의 껍질을 덮어쓴 HTTP라고 할 수 있다. 즉, HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아니라는 것이다. HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer) or TLS(Transfer Layer Security)라는 프로토콜을 대체하는 것 뿐이다. HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고, SSL이 TCP와 통신하게 된다. SSL을 사용한 HTTPS는 암호화와 증명서, 안정성 보호를 할 수 있게 된다.

HTTPS의 SSL에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다. 공통키를 공개키 암호화 방식으로 교환한 다음에 다음부터의 통신은 공통키 암호를 사용하는 방식이다.

모든 웹페이지를 HTTPS를 사용해도 될까?

평문 통신에 비해 암호화 통신은 CPU나 메모이 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다.

하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라고 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함꼐한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용했지만, 현재는 모든 웹페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.

HTTP의 GET과 POST 비교

둘 다 HTTP 프로토콜을 이용해서 서버에 무엇인가를 요청할 때 사용하는 방식이다. 하지만 둘의 특징을 제대로 이해하여 기술의 목적에 맞게 알맞은 용도에 사용해야 한다.

GET

GET 방식은 어떠한 데이터를 조회하기 위해 사용되는 방식이다.

특징

• URL에 변수(데이터)를 포함시켜 요청한다.
• 데이터를 Header(헤더)에 포함시켜 전송한다.
• URL에 데이터가 노출되어 있어 보안에 취약하다.
• 캐싱이 가능하다.

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

ex) 
url:	https://search.naver.com/search.naver?query=velog
-> 	네이버에 'velog'라는 키워드를 검색한 결과. 
	이 때에 query라는 파라미터에 velog라는 데이터를 담아서 보낸 것이다.

Caching(캐싱)

한번 접근 후, 이후에 다시 요청할 시 데이터에 빠르게 접근하기 위해 레지스터에 데이터를 저장시켜 놓는 것.

POST

POST 방식은 데이터를 서버로 보냄으로써 데이터를 추가 또는 수정하기 위애 사용하는 방식이다.

특징

• URL에 변수(데이터)를 노출시키지 않고 요청한다.
• 데이터를 Body(바디)에 포함시킨다.
• URL에 데이터를 노출되지 않기에 기본 보안은 되어있다.
• 캐싱이 불가능하다.

POST 방식의 request는 HTTP Request Message의 Body 부분에 데이터가 담겨서 전송된다. 때문에 바이너리 데이터를 요청하는 경우 POST 방식으로 보내야 하는 것처럼 데이터 크기가 GET 방식보다는 크고 보안면에서는 낫다. 하지만 암호화를 하지 않는 이상 보안적인 측면은 고만고만하다. POST 방식은 Header 부분에 Content-Type에 Body의 데이터가 어떤 데이터 타입인지 지정해야 한다.
POST 방식은 URL에 데이터가 노출되지 않으므로 캐싱이 불가능하지만 쿼리스트링(문자열) 데이터 뿐 아니라 라디오 버튼, 텍스트 박스와 같은 객체들의 값도 전송이 가능하다.

GET과 POST 비교

위의 내용을 기준으로 비교 해보면 아래와 같다.

	GET	POST
URL에 데이터 노출 여부	O	X
URL 형식	http://localhost:8080/board?name=제목&contents=내용	http://localhost:8080/board
데이터의 위치	Header	Body
캐싱 가능 여부	O	X

 

---

TCP 3 way-Handshake & 4 way-Handshake

클라이언트와 서버가 통신을 하기 전 정확한 전송을 보장하기 위해 컴퓨터간 세션을 수립하는 과정으로써, TCP 프로토콜에서 신뢰성을 보장하기 위해 사용된다.

TCP 3 way-Handshake 역할

• 양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장하고, 실제로 데이터 전달이 시작되기 전에 한쪽이 다른 쪽이 준비되었다는 것을 알 수 있도록 한다.
• 양쪽 모두 상대편에 대한 초기 순차일련번호를 얻을 수 있도록 한다.

TCP 3 way-Handshake 과정

연결 성립 (Connection Establishment)

1. 클라이언트는 서버에 접속을 요청하는 SYN(a) 패킷을 보낸다.
2. 서버는 클라이언트의 요청인 SYN(a)을 받고 클라이언트에게 요청을 수락한다는 ACK(a+1)와 SYN(b)이 설정된 패킷을 발송한다.
3. 클라리언트는 서버의 수락 응답인 ACK(a+1)와 SYN(b) 패킷을 받고 ACK(b+1)를 서버로 보내면 연결이 성립(establish)된다.

TCP 4 way-Handshake 과정

연결 해제 (Connection Termination)

1. 클라이언트가 연결을 종료하겠다는 FIN플래그를 전송한다.
2. 서버는 클라이언트의 요청(FIN)을 받고 알겠다는 확인 메세지로 ACK를 보낸다.
   2-1. 그리고 나서 데이터를 모두 보낼 때까지 잠깐 TIME_OUT이 된다.
3. 데이터를 모두 보내고 통신이 끝났으면 연결이 종료되었다고 클라이언트에게 FIN 플래그를 전송한다.
4. 클라이언트는 FIN 플래그를 확인했다는 메세지(ACK)를 보낸다.
5. 클라이언트의 ACK 메세지를 받은 서버는 소켓 연결을 close한다.
6. 클라이언트는 아직 서버로부터 박지 못한 데이터가 있을 것을 대비해 일정 시간동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거친다. (**TIME_WAIT)

SYN? ACK?

아래는 두 용어의 약자이다.

SYN: SYnchronize sequence Numbers
ACK: ACKnowledgment

TCP Header에는 Code Bit(Flag bit)라는 부분이 존재한다. 이 부분은 총 6Bit로 이루어져 있으며 각각 하나의 bit마다 의미를 갖고 있다. Urg-Ack-Psh-Rst-Syn-Fin 순서로 되어있으며, 해당 위치의 bit가 1이면 해당 패킷이 어떠한 내용을 담고 있는 패킷인지를 나타낸다. 예를 들면 SYN 패킷의 경우에는 000010이 되고 ACK 패킷의 경우에는 010000이 된다.

두 종류의 패킷을 사용하는 이유

연결을 성립하기 위해서는 서로 통신이 가능한지 파악해야 한다. 이를 위해 패킷을 먼저 주고 받아야 한다. 하지만 굳이 두 종류의 패킷을 사용하는 이유는 요청과 응답에 대한 패킷을 주고 받아야 하기 때문이다.

2way가 아닌 3way인 이유

클라이언트가 서버에게 패킷을 보내 통신이 가능한지 확인하는 것과 별개로 그 반대인 서버가 클라이언트에게 패킷을 보내 클라이언트가 잘 수신하는지 확인할 필요가 있기 때문이다. 따라서 2way로는 부족하다.

비유를 들어보자.
클라이언트가 서버에게 자신의 목소리가 들리는지 물어본다 (SYN)
서버는 클라이언트의 목소리다 들린다고 말한다.(SYN+1) 그리고 자신의 목소리가 들리는지 물어본다.(ACK)
클라이언트는 서버의 목소리가 잘 들린다고 말한다.(ACK+1)

위와 같은 과정으로 서로 통신이 가능한지 확인한다.

sequence number가 난수인 이유

처음 클라이언트에서 SYN 패킷을 보낼 때 Sequence Number에는 랜덤한 숫자가 담겨진다. 초기 Sequence Number를 ISN이라고 한다. ISN이 0부터 시작하지 않고 난수를 생성해서 number를 설정하는 이유는 무엇인가?
Connection을 맺을 때 사용하는 포트(port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다. 서버 측에서는 패킷의 SYN을 보고 패킷을 보고 패킷을 구분하게 되는데, 난수가 아닌 순차적인 number가 전송된다면 이전의 connection으로부터 오는 패킷으로 인식할 수 있다. 이러한 문제를 발생할 가능성을 줄이기 위해 난수로 ISN을 설정한다.

 

---

TCP / UDP

TCP

연결지향형 전송규약

• 흐름중심 프로토콜. 통신을 주고받는 것을 중요시한다.
• 중간에 패킷이 손실되는 경우 재전송을 통해(SYN-ACK handshaking) 신뢰성을 보장한다
  • 속도는 느리지만 대부분의 통신에서 사용된다. 특히 파일이나 데이터 전송 시에 사용된다.
• 바이트 스트림 서비스로 데이터 경계 구분이 없다.

UDP

비연결지향형 전송규약

• 데이터중심 프로토콜. 주고받는 통신보다는 데이터를 일방적으로 보내는 것을 중요시한다.
  • 데이터 전송의 신뢰성 보장하지 못하지만, 속도는 빠르다.
• P2P, 스트리밍, 전화 등에서 사용

TCP vs UDP

프로토콜 종류	TCP	UDP
연결방식	연결지향형 전송규약	비연결지향형 전송규약
패킷 교환 방식	세그먼트 방식	데이터그램 방식
전송 순서 보장	O	X
수신 여부 확인	O	X
통신 방식	1:1	1:1 / 1:N / N:N
신뢰성	높다	낮다
속도	느리다	빠르다

 

---

웹 통신의 큰 흐름

웹 브라우저에서 주소창에 특정 URL을 입력하면 일어나는 일

1. 브라우저

1. URL에 입력된 겂울 브라우저 내부에서 결정된 규칙에 따라 그 의미를 조사한다.
2. 조사한 의미에 따라 HTTP Request 메세지를 만든다.
3. 만들어진 메세지를 웹서버로 전송한다.

이 때 만들어진 메세지 전송을 브라우저가 직접 하는 것이 아니다. 브라우저는 메세지를 네트워크에 송출하는 기능이 없으므로 OS에 의뢰하여 메세지를 전달한다. 비유를 하자면 우리가 택배를 보낼 때 직접 보내는 것이 아니라, 이미 서비스가 이루어지고 있는 택배 시스템(택배 회사)을 이용하여 보내는 것과 같다. 단, OS에 송신을 의뢰할 때는 도메인명이 아니라 ip주소로 메세지를 받을 살대를 지정해야 하는데, 이 과정에서 DNS서버를 조회해야 한다.

2. 프로토콜 스택, LAN 어댑터

1. 프로토콜 스택(운영체제에 내장된 네트워크 제어용 소프트웨어)이 브라우저로부터 메세지를 받는다.
2. 브라우저로부터 받은 메세지를 패킷 속에 저장한다.
3. 패킷에 수신처 주소 등의 제어정보를 덧붙인다.
4. 패킷을 LAN 어댑터에 넘긴다.
5. LAN 어댑터는 다음 Hop의 MAC주소를 붙인 프레임을 전기신호로 변환시킨다.
6. 신호를 LAN 케이블에 송출시킨다.

프로토콜 스택은 통신 중 오류가 발생했을 때, 이 제어정보를 사용하여 고쳐 보내거나, 각종 상황을 조절하는 등 다양한 역할을 하게 된다. 네트워크 세계에서는 비서가 있어서 우리가 비서를 물만 건네주면, 받는 사람의 주소와 각종 유의사항을 써준다. 여기서는 프로토콜 스택이 비서의 역할을 한다고 볼 수 있다.

3. 허브, 스위치, 라우터

1. LAN 어댑터가 송신한 프레임은 스위칭 허브를 경유하여 인터넷 접속용 라우터에 도착한다.
2. 라우터는 패킷을 프로바이더(통신사)에게 전달한다.
3. 패킷이 인터넷으로 들어가게 된다.

4. 액세스 회선, 프로바이더

1. 패킷을 인터넷의 입구에 있는 액세스 회선(통신 회선)에 의해 POP(Point Of Presence, 통신사용 라우터)까지 운반된다.
2. POP를 거쳐 인터넷의 핵심부로 들어가게 된다.
3. 수 많은 고속 라우터들 사이로 패킷이 목적지를 향해 흘러가게 된다.

5. 방화벽, 캐시서버

1. 패킷은 인터넷 핵심부를 통과하여 웹서버 측의 LAN에 도착한다.
2. 기다리고 있던 방화벽이 도착한 패킷을 검사한다.
3. 패킷이 웹서버까지 가야하는지, 가지 않아도 되는지 판단하는 캐시서버가 존재한다.

굳이 서버까지 가지 않아도 되는 경우를 골라낸다. 액세스한 페이지의 데이터가 캐시서버에 있으면 웹서버에 의뢰하지 않고 바로 그 값을 읽을 수 있다. 페이지의 데이터 중에 다시 이용할 수 있는 것이 있으면 캐시 서버에 저장된다.

6. 웹서버

1. 패킷이 물리적인 웹서버에 도착하면 웹서버의 프로토콜 스택은 패킷을 추출하여 메세지를 복원하고 웹서버 애플리케이션에 넘긴다.
2. 메세지를 받은 웹서버 애플리케이션은 요청 메세지에 따른 데이터를 응답 메세지에 넣어 클라이언트로 회송한다.
3. 왔던 방식과 동일하게 응답 메세지가 클라이언트에 전달된다.

 

참고
https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Network
https://mangkyu.tistory.com/17
https://asfirstalways.tistory.com/356
https://tuhbm.github.io/2017/09/08/OSI7/
https://ryusae.tistory.com/4
https://mindnet.tistory.com/entry/네트워크-쉽게-이해하기-22편-TCP-3-WayHandshake-4-WayHandshake