[기술면접] 네트워크 부분 예상 질문과 답변

틀린 부분이 있다면 댓글에 남겨주세요!!

 

1. OSI(open systems interconnection reference model) 7계층이란

OSI 7계층이란 통신 접속에서 완료하기까지의 과정을 7단계로 정의한 국제 통신 표준 규약을 말합니다.

OSI 7계층의 최하위계층부터 말씀드리겠습니다. 물리계층은 통신 케이블로 데이터를 전송하는 역할을 하며 데이터 전송 단위는 비트입니다. 데이터 링크 계층은 포인트 투 포인트 간 신뢰성있는 정보를 보장하기 위한 계층으로 CRC기반의 오류 제어와 흐름 제어가 필요합니다. 대표적인 예로 이더넷이 있으며 데이터 전송 단위는 프레임입니다. 네트워크 계층은 여러 노드를 거칠때마다 경로를 찾아주는 역할을 합니다. 네트워크 계층은 라우팅, 흐름제어, 세그멘테이션, 오류제어, 인터네트워킹 등을 수행합니다. 데이터 전송 단위는 패킷입니다. 전송계층은 양 끝단의 사용자들이 신뢰성있는 데이터를 주고받을 수 있도록 해줍니다. 전송 계층이 패킷들의 전송이 유효한지 확인하고 전송 실패한 패킷들은 다시 전송합니다. 대표적인 예로는 TCP가 있고 전송 단위는 세그먼트입니다. 세션 계층은 양 끝단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공합니다. 동시 송수신 방식, 반이중 방식, 전이중 방식의 통신을 사용합니다. 표현 계층은 코드 간의 번역을 담당합니다. MIME인코딩이나 암호화 동작을 수행합니다. 응용 계층은 응용 프로세스와 함께 일반적인 응용 서비스를 수행합니다. 일반적인 응용 서비스는 관련된 응용 프로세스들 사이의 전환을 제공합니다.

* 물리~네트워크는 미디어 계층, 전송~응용 계층은 호스트 계층

 

2. TCP IP의 개념

TCP/IP 프로토콜에 대해 설명하기 위해서는 먼저 TCP와 IP의 정의부터 알아야 합니다.

TCP는 두 호스트간 데이터 전달을 관리하는 규칙입니다. TCP는 데이터 패킷에 일련의 번호를 부여해 패킷을 조립하고 손실된 패킷을 확인하며 재전송하도록 요청합니다.

IP는 컴퓨터의 주소입니다. IP는 그저 데이터를 전달하는 역할만 담당하며 IP주소는 임시적으로 통신사에게 받는 주소이므로 변경될 수 있습니다.

TCP/IP 프로토콜은 IP기반의 TCP를 사용한 프로토콜을 말합니다. TCP는 패킷의 추적 및 관리를, IP는 데이터의 배달을 담당하고 있습니다. TCP/IP 4계층은 통신에 실제 사용되는 계층을 말합니다. 네트워크 엑세스 계층, 인터넷계층, 전송계층, 응용계층으로 구성되어 있습니다. 네트워크 엑세스 계층은 OSI 7계층의 물리 계층과 데이터 링크 계층에 해당합니다. 인터넷계층은 네트워크 계층에 해당하고 전송 계층은 7계층의 전송 계층과 같습니다. 응용계층은 7계층에서 세션계층, 표현계층, 응용 계층에 해당합니다. TCP/IP 4계층은 통신이 일어나는 과정을 단계별로 파악하기 때문에 문제 발생시 트러블 슈팅이 용이합니다.

 

3. TCP와 UDP

Tcp(transmission control protocol)와 udp(user datagram protocol)는 전송 계층에서 사용하는 프로콜입니다. TCP는 인터넷 상에서 데이터를 세그먼트 형태로 보내기 위해 ip와 함께 사용하는 프로콜입니다. Ip가 데이터의 배달을 처리하면 tcp는 데이터 패킷에 일련의 번호를 부여함으로써 패킷을 추적하고 관리합니다. 또한, tcp는 연결형 서비스로 가상 회선 방식을 제공합니다. 3-way handshaking과정을 통해 연결을 설정하고, 4-way handshaking을 통해 연결을 해제합니다. 흐름제어(데이터 송신하는 곳과 수신하는 곳의 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지하는 것) 및 혼잡제어(네트워크 내의 패킷 수가 지나치게 증가하지 않도록 방지하는 것)도 제공합니다. 높은 신뢰성을 보장하며 전이중(전송이 양방향으로 동시에 일어나는 것), 점대점(각 연결이 2개의 종단점을 가지고 있는 것) 방식입니다. 하지만 처리해야 하는 것이 많기 때문에 udp보다는 속도가 느립니다.

Udp는 데이터를 데이터그램 단위로 처리하는 프로토콜을 말합니다. 비연결형 서비스로 데이터그램 방식을 제공합니다. 연결을 위해 할당되는 논리적인 경로가 없기 때문에 각각의 패킷은 서로 다른 경로로 전송됩니다. (상대방이 받든지 말든지 그냥 보냄)신뢰성이 낮지만 udp헤더의 checksum필드를 통해 최소한의 오류는 검출하는 과정을 거칩니다. tcp보다 속도가 빠르며 실시간 서비스 같이 신뢰성보다는 연속성이 중요한 서비스에 사용됩니다.

 

5. TCP의 3 way handshake와 4 way handshake

3 way handshake란 tcp 통신을 이용하여 데이터를 전송하기 위한 네트워크 연결을 설정하는 과정을 말합니다. 연결을 설정하는 과정은 다음과 같습니다. 클라이언트가 서버에게 처음 데이터를 전송할 때는 시퀀스 넘버를 임의의 랜덤 숫자로 지정하고 syn플래그 비트를 1로 설정한 세그먼트를 전송합니다. 이때 클라이언트는 closed, 서버는 listen상태가 됩니다. 메시지를 정상적으로 받은 서버는 클라이언트의 요청을 수락한다는 ack과 syn 플래그가 1로 설정된 세그먼트를 전송합니다. 이떄 서버는 syn-received상태가 됩니다. 다시 서버의 메시지를 정상적으로 받은 클라이언트는 서버에게 ack메시지를 보내고 established상태가 됩니다. 서버가 클라이언트의 패킷을 무사히 받으면 서버도 established상태가 되며 둘의 연결이 맺어지게 됩니다.

4 way handshake란 tcp의 연결을 해제하는 과정을 말합니다. 해제 과정은 다음과 같습니다. 클라이언트가 서버에게 연결을 종료하겠다는 fin플래그를 전송합니다. 이때 클라이언트의 상태는 fin_wait으로 바뀝니다. 플래그를 받은 서버는 close_wait 상태로 변경되며 ack메세지를 보냅니다. 그리고 전송할 데이터가 남아있다면 이어서 계속 전송합니다. 이후 서버는 통신이 끝났다면 연결 종료를 위해 fin플래그를 클라이언트에게 전송합니다. 플래그를 받은 클라이언트는 time_wait상태로 변경되며 ack을 서버에게 전송합니다. Ack을 받은 서버는 closed상태로 변경되며 일정 시간이 경과한 후 클라이언트도 closed상태로 변경되며 연결이 종료됩니다.

Q. TCP의 연결 설정 과정(3단계)과 연결 종료 과정(4단계)이 단계가 차이나는 이유?

서버가 남은 데이터를 전송하는 과정 때문에 차이가 발생합니다. 클라이언트가 데이터 전송을 마쳤다고 하더라도 서버는 아직 보낼 데이터가 남아있을 수 있기 때문에 서버는 먼저 fin에 대한 ack만 전송합니다. 이후 데이터를 모두 전송하면 최종적으로 fin메시지를 보내게 되며 연결이 해제됩니다.

Q. 만약 Server에서 FIN 플래그를 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황이 발생하면 어떻게 될까?

이를 대비하기 위해 클라이언트는 서버로부터 fin플래그를 수신하더라도 일정시간 동안 세션을 남겨 놓고 다른 패킷을 기다리는 과정을 거칩니다. 이때의 상태를 time_wait이라고 합니다.

 

6. HTTP 요청 흐름 (웹 브라우저에서의 흐름)

유저가 입력창에 url을 입력하게 되면  브라우저에서 url에 적힌 값을 파싱하여 http 요청 메시지를 만듭니다. 이 메시지를 웹 서버로 전송하게 되는데 이때 웹 브라우저가 직접 전송하는 것이 아니라 운영체제에 전송을 요청합니다. 운영체제는 dns서버를 조회해서 (host이름을 보내야 할) ip주소로 변환하게 됩니다.

프로토콜 스택(OS에 내장된 네트워크 제어용 소프트웨어, TCP/IP 계층)과 LAN 어댑터에서 브라우저로부터 메시지를 받습니다. 브라우저로부터 받은 메시지를 패킷 속에 저장하고 수신주소를 제어정보에 덧붙입니다. 그 후 패킷은 LAN어댑터에 넘기게 되고 LAN어댑터는 패킷을 전기신호로 변환시켜 LAN케이블에 송출하게 됩니다.

허브, 스위치, 라우터에서는 LAN어댑터가 송신한 패킷을 수신합니다. 라우터는 패킷을 ISP(internet service provider)에 전달하고 패킷은 인터넷으로 들어가게 됩니다.

패킷은 인터넷 입구에 있는 액세스 회선에 의해 통신사용 라우터(POP, point of presence)까지 전송되고 POP를 거쳐 인터넷의 핵심부로 들어가게 됩니다. 수많은 고속 라우터들 사이로 목적지까지 패킷이 흘러가게 됩니다.

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

패킷이 물리적 웹 서버에 도착하게 되면 웹 서버의 프로토콜 스택이 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘기게 됩니다. 애플리케이션은 요청에 대한 응답 데이터를 넣어 클라이언트로 보내게 됩니다.

 

7. HTTP와 HTTPS

HTTP란 hypertext transfer protocol의 약자로 웹 상에서 클라이언트와 서버 간에 요청과 응답을 통해 정보를 주고 받을 수 있는 프로토콜을 말합니다. 주로 html문서(웹페이지는 텍스트)를 주고받는 데에 쓰이며 비연결(connectionless)과 비상태(stateless) 특성을 가집니다. 비연결은 클라이언트가 서버에 요청을 보내고 서버가 적절한 응답을 보내오면 연결이 바로 끊기는 것을 말합니다. 비상태란 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않는 것을 말합니다. 하지만 HTTP는 평문 통신이기 때문에 도청이 가능하고 위장이나 변장이 가능하다는 단점이 존재합니다.

* TLS는 SSL이 표준화되면서 바뀐 이름

이러한 HTTP의 보안 문제를 해결하기 위해 나온 것이 HTTPS입니다. HTTPS는 웹 상에서 정보를 암호화하는 SSL(secure socket layer)이나 TLS(transport layer security) 프로토콜을 통해 세션 데이터를 암호화합니다. 따라서 데이터의 적절한 보호를 보장합니다. HTTPS는 암호화, 복호화를 할 시 공개키 알고리즘 방식을 사용합니다. 공개키(암호화에 사용)는 모두에게 공개하지만 개인키(복호화에 사용)는 서버만이 가지고 있습니다. 이렇듯 HTTPS는 네트워크 상에서 열람, 수정이 불가능하므로 안전하다는 장점이 있지만 암호화 과정이 웹 서버에 부하를 줄 수 있다는 단점이 존재합니다.

* 추가설명(꼭 안말해도됨)

또한 설치 및 인증서를 유지하는데 추가 비용이 발생하고 HTTP에 비해 느립니다. 또한 인터넷 연결이 끊길 경우 재인증 시간이 소요됩니다. (인터넷 끊기면 소켓(데이터를 주고 받는 경로)도 끊어져서 다시 인증해야됨)

 

8. CORS(cross origin resource sharing)

CORS란 HTTP 헤더를 사용해서 애플리케이션이 다른 출처(도메인, 프로토콜, 포트)를 가진 자원에 접근할 수 있도록 하는 정책을 말합니다. CORS는 브라우저에서 구현됩니다. 브라우저는 실제 요청을 보내도 안전한지 판단하기 위해 서버에 preflight 요청을 먼저 보냅니다. option메소드로 전송하게 되고 요청을 받은 서버는 자신이 어떤 것들을 허용하고 금지하고 있는지에 대한 정보를 헤더에 담아 브라우저에게 다시 보내줍니다. 이때 응답 헤더에는 Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Headers, Access-Control-Allow-Methods 등이 담겨 있습니다. origin헤더는 접근 가능한 url을 설정하고 credentials 헤더는 접근 가능한 쿠키를 설정합니다. 또한, headers 헤더는 접근 가능 헤더, methods 헤더는 접근 가능 메서드를 설정합니다. 이후 브라우저는 preflight 요청과 서버가 보내준 허용 정책을 비교하여 이 요청이 안전하다고 판단되면 다시 실제 요청을 보내게 됩니다. 이후 서버가 응답하면 최종적으로 응답 데이터를 자바스크립트에게 넘겨주게 됩니다.

* SOP(same origin policy)란 같은 출처에서만 자원을 공유할 수 있다는 정책이다.

 

9. GET 메서드와 POST 메서드

GET메서드와 POST메서드는 HTTP 프로토콜을 이용해서 서버에 데이터를 전달할 때 사용하는 방식을 말합니다. 먼저 GET메서드 방식에 대해서 말씀드리겠습니다. GET메서드는 서버에서 데이터를 가져와 조회하기 위해 사용하는 메서드입니다.(select) (url끝에 ?가 붙고 요청 정보가(key=value)형태로 붙음

=> www.urladdress.xyz?name1=value1&name2=value2) http 패킷의 바디는 비어 있는 상태로 전송합니다. 또한, url에 요청 정보를 붙여서 전송하기 때문에 데이터 길이가 길어져 대용량의 데이터를 전송하기는 어렵고 요청 정보를 쉽게 확인할 수 있기 때문에 보안에 취약하다는 단점이 존재합니다. 하지만 post방식보다는 속도가 빠르다는 장점이 있습니다.

POST 메서드는 서버의 값이나 상태를 바꾸기 위해 사용하는 메서드입니다.(insert, update, delete) POST메서드는 요청 정보를 http패킷의 body안에 숨겨서 서버로 전송합니다. 때문에 대용량의 데이터를 전송하기에 적합하고 보안상 안전하다는 장점이 존재합니다. 클라이언트 쪽에서 데이터를 인코딩하여 서버로 전송하고 이를 받은 서버쪽이 해당 데이터를 디코딩하는 방식입니다.

 

10. 쿠키와 세션

쿠키와 세션은 HTTP프로토콜에서 상태를 유지하기 위해 사용합니다. 쿠키는 클라이언트 로컬에 저장되는 키와 값이 들어있는 파일입니다. 웹브라우저가 서버에 요청을 보내면 웹 서버는 쿠키를 생성합니다. 서버는 응답시 HTTP헤더에 쿠키를 포함해서 전송하고 전달받은 쿠키는 웹브라우저에서 관리하다가 다음 요청때 쿠키를 http헤더에 넣어서 전송합니다. 서버에서는 쿠키 정보를 읽어 이전 상태 정보를 확인한 후 응답합니다.

세션이란 웹 브라우저를 통해 서버에 접속한 이후부터 브라우저를 종료할 때까지 유지되는 상태를 말합니다. 웹브라우저가 서버에 요청하면 서버는 해당 웹브라우저에 유일한 세션 아이디를 부여합니다. 서버가 응답할 때 http헤더에 세션 아이디를 포함해서 전송합니다. 웹브라우저는 이후 웹브라우저가 종료되기까지 세션아이디가 담긴 쿠키를 http 헤더에 넣어서 전송합니다. 서버는 이를 확인하고, 적절한 응답을 합니다.

쿠키와 세션에는 몇가지 차이점이 존재합니다. 쿠키는 클라이언트에, 세션은 서버에 저장됩니다. 쿠키는 보안에 취약하지만 세션은 비교적 보안성이 좋습니다. 또한, 쿠키는 브라우저를 종료해도 남을 수 있지만 세션은 종료 즉시 삭제됩니다. 쿠키는 클라이언트에 저장되기 때문에 속도가 빠르지만 세션은 서버의 처리가 필요해 쿠키보다는 느립니다.

 

11. DNS(domain name system)

DNS(domain name system)란 도메인을 ip로 바꿔주는 시스템을 말합니다. DNS는 호스트 또는 도메인의 IP정보를 저장하여 사용자에게 제공하고 이 덕분에 사용자는 많은 사이트를 도메인 네임으로 쉽게 접속할 수 있습니다. 

도메인 네임 시스템의 요소 중의 도메인에 연결된 서버IP를 찾는 역할을 하는 것은 DNS(domain name server)입니다. 도메인 네임 서버는 할당된 도메인 영역에 대한 정보를 가지고 있는 서버로 클라이언트가 도메인을 입력하면 해당 도메인과 연결된 DNS서버로 접속해 서버 IP를 요청합니다. 도메인 네임 서버는 해당 도메인의 IP주소를 찾아 클라이언트에게 전달하고 클라이언트는 해당 주소로 접속할 수 있게 됩니다.

 

12. REST와  RESTful의 개념

1) REST 정의 및 구체적 개념

REST는 representational state transfer(=대표적인 상태 전달)의 약자로 분산 하이퍼미디어 시스템(WWW와 같은)을 위한 소프트웨어 개발 아키텍처의 한 형식입니다. 웹의 기존 기술과 HTTP프로토콜을 모두 활용하기 때문에 웹의 장점을 최대한 사용할 수 있습니다. REST는 HTTP URI(uniform resource identifier)를 통해 자원을 명시하고 HTTP 메소드(get, post, put, delete, head)를 이용하여 해당 자원에 대한 CRUD(create, read, update, delete, head(헤더정보조회)) operation을 적용합니다. (즉, REST는 자원 기반의 구조 설계로 설계 중심에 자원이 있고 HTTP 메소드를 통해 자원을 처리하도록 설계된 아키텍처를 의미합니다. 웹 사이트의 모든 자원에 HTTP URI를 부여합니다.)

2) REST 장단점

REST는 여러 장점을 갖고 있습니다. 먼저, HTTP 프로토콜 인프라를 그대로 사용하기 때문에 별도의 인프라를 구축하지 않아도 됩니다. 또한, HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하며 Hypermedia API의 기본을 지키기 때문에 범용성을 보장합니다.

하지만 REST는 명확한 표준이 없고 각 서비스별로 아키텍처가 달라 이에 따른 서비스 방안도 다르다는 단점이 있습니다.

3) REST 필요이유(안물어보면 괜히 말하지 말자)

REST가 필요한 이유는 다양한 클라이언트가 등장했기 때문입니다. 이전에는 웹 페이지를 위한 HTML과 이미지를 보냈기 때문에 다른 플랫폼에서 받아들이는 것이 힘들었는데 이제는 REST를 사용하여 데이터만 주고받고 클라이언트가 적절히 데이터를 보여주면 되기 때문에 REST의 사용으로 클라이언트의 부담이 줄어들었습니다.

4) REST 구성요소

REST는 자원, 행위, 표현으로 이루어져 있습니다. 모든 자원에는 고유 아이디인 HTTP URI (uniform resource identifier의 약자, 인터넷에 있는 자원을 나타내는 유일한 주소로 다음과 같은 형태 => /groups/:group_id)가 할당되고 이 자원은 서버에 존재합니다. 클라이언트는 URI를 이용해서 자원을 지정하고 해당 자원의 상태에 대한 조작을 서버에 요청합니다. 행위는 HTTP프로토콜의 메소드(GET, POST, DELETE, PUT, HEAD)를 사용하는 것을 말합니다. 표현은 클라이언트가 자원의 정보에 대한 조작을 요청하면 서버가 이에 적절한 응답을 보내주는 것을 말합니다. REST에서 자원은 JSON, XML, TEXT, RSS등의 여러 형태로 되어있는데 주로 JSON이나 XML을 통해 데이터를 주고받습니다.

5) REST 특징

REST는 유니폼 인터페이스 스타일을 가지고 있습니다. 이는 http표준만 따른다면 어떤 언어나 플랫폼에서도 사용이 가능한 인터페이스 스타일입니다. 또한 서버-클라이언트 구조이며 비상태를 지향하고 캐시가 가능하며 계층화 구조를 갖고 있습니다.

6) REST APT 정의 및 특징

REST API란 REST를 기반으로 서비스 API를 구현한 것을 말합니다. REST API는 REST를 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운영을 편리하게 할 수 있고 서버-클라이언트 구조를 구현할 수 있습니다.

7) REST API 설계 기본 규칙과 일반 규칙

REST API를 설계하기 위해선 기본 규칙과 일반 규칙이 존재합니다. 기본규칙은 총 2가지가 있습니다. 첫번째 규칙은 URI는 정보의 자원을 표현해야 한다는 것입니다. (자원은 동사보다는 명사를 사용하며 소문자 복수형을 사용하여 표현해야 합니다) 두번째 규칙은 자원에 대한 행위는 HTTP 메서드로 표현한다는 것입니다. (URI에 HTTP 메서드나 행위에 대한 동사 표현이 들어가면 안됩니다) 일반 규칙에는 8가지가 존재합니다. 슬래시 구분자는 계층 관계를 나타내는데 사용하지만 URI 마지막 문자에는 포함하지 않아야 합니다. 하이픈은 URI 가독성을 높이는데 사용하지만 밑줄은 URI에 사용하지 않습니다. URI경로에는 소문자가 적합하며 파일확장자는 URI에 포함하지 않습니다. 자원 간에 연관 관계가 있는 경우에는 /자원명/자원 ID/관계가 있는 다른 자원명과 같은 형태로 표현할 수 있습니다. 마지막으로 콜론id는 특정 자원을 나타내는 고유값입니다.

8) RESTful의 개념

RESTful은 REST를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어입니다. RESTful은 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것이 주 목적입니다. 하지만 CRUD기능을 모두 POST로 처리하는 API나 루트에 자원, 아이디 외의 정보가 들어가는 경우에는 RESTful을 사용할 수 없습니다.

***프론트엔드에서 RestfulApi get, put, post, patch, option, delete)를 물어본다고 해서 정리

GET메소드는 요청받은 URI의 정보를 검색하여 응답합니다. POST메소드(멱등X)는 요청된 자원을 생성(CREATE)합니다. PUT(멱등O)과 PATCH(멱등X)메소드는 요청된 자원을 수정(UPDATE)한다는 공통점이 있습니다. 하지만 PUT은 자원 전체를 갱신하지만 PATCH는 해당자원의 일부만 교체한다는 차이점이 있습니다. DELETE는 요청된 자원을 삭제해달라고 요청하고 OPTIONS메소드는 웹서버에서 지원되는 메소드의 종류를 확인할 때 사용합니다.

* POST는 매번 새로운 자원을 생성해내지만 PUT은 자원의 위치가 지정되기 때문에 자원을 새로 생성하지 않는다.

 

13. 소켓이란

소켓은 IP주소와 Port넘버가 합쳐져 네트워크상에서 서버와 클라이언트가 통신할 수 있도록 해주는 소프트웨어 장치를 말합니다.

 

14. Socket.io와 WebSocket의 차이

WebSocket이란 실시간으로 상호작용하는 웹 서비스를 만드는 표준 기술을 말합니다. HTTP 프로토콜은 단방향 통신을 위해 만들어진 방법이었기 때문에 실시간 웹을 구현하기 위해서는 polling이나 streaming방식의 AJAX(JavaScript를 사용한 비동기 통신을 말하며, 클라이언트와 서버간에 XML데이터를 주고받은 기술입니다)코드를 이용할 수밖에 없었습니다. 하지만 해당 방법들은 브라우저마다 구현 방법이 달라 개발의 어려움이 있었고 이를 해결하기 위해 웹소켓이 만들어졌습니다.

웹소켓은 소켓을 이용하여 자유롭게 데이터를 주고받을 수 있고 일반 HTTP request를 통해 handshaking과정을 거쳐 최초 접속이 이루어집니다. http:// 대신 ws://로 시작하며 브라우저와 마찬가지로 웹 서버도 웹소켓 기능을 지원해야 합니다. 또한, 웹소켓 프로토콜은 아직 확정된 상태가 아니어서 브라우저별로 지원하는 버전이 다릅니다. 웹소켓은 HTTP request를 그대로 사용하기 때문에 추가로 방화벽을 열지 않고도 양방향 통신이 가능하며 HTTP 규격인 CORS적용이나 인증 등의 과정을 거쳐 기존과 동일하게 사용할 수 있다는 장점이 있습니다.

Socket.io는 실시간 웹 기술을 쉽게 사용할 수 있는 모듈을 말합니다. JavaScript를 이용하여 브라우저 종류에 상관없이 실시간 웹을 구현할 수 있도록 하는 기술입니다. 또한 Socket.io는 지금 당장 사용할 수 있는 기술이며 서버 구현체가 Node.js밖에 없습니다. Socket.io를 사용하면 웹소켓을 지원하지 않는 브라우저라도 푸쉬 메시지를 일관된 모듈로 보낼 수 있다는 장점이 존재합니다.

 

15. PDU (Protocol data unit)

PDU는 프로토콜 데이터 단위를 말하며 데이터 통신에서 상위 계층이 전달한 데이터에 붙이는 제어정보를 뜻하며 각 계층의 데이터 단위입니다. 물리 계층은 비트, 데이터링크 계층은 프레임, 네트워크 단위는 패킷, 전송 계층은 세그먼트, 세션, 표현, 응용 계층은 데이터입니다.

 

16. 데이터 캡슐화

PDU는 SDU(service data unit)와 PCI(protocol control information)로 구성되어 있습니다. SDU는 전송하려는 데이터고, PCI는 프로토콜 제어 정보입니다. PCI에는 송신자와 수신자 주소, 오류 검출 코드, 프로토콜 제어 정보 등이 있습니다. 캡슐화란 상위계층에서 하위계층에게 데이터에 필요한 정보(헤더)를 붙여서 다음 계층에 보내는 기술을 말합니다. 이와 반대로 하위계층에서 상위계층으로 넘어가며 데이터의 헤더를 제거하는 것을 역캡슐화라고 합니다.

 

* 기타

Host란 네트워크 주소가 할당된 노드(네트워크 공간 상에 있는 모든 장치)를 말합니다.

서버란 요청에 응답할 수 있는 호스트를 의미합니다.

클라이언트란 네트워크 상에서 요청하는 호스트를 말합니다.

포트는 네트워크를 통해 데이터를 주고받는 프로세스를 식별하기 위해 호스트 내부적으로 프로세스가 할당받는 고유값을 말합니다.

프로토콜이란 서로 다른 하드웨어와 운영체제 간의 통신을 위해서 필요한 규칙