[컴네/CN] 프로토콜 및 소켓

TCP/IP 프로토콜 계층

왼쪽이 TCP/IP, 오른쪽이 osi 프로토콜 계층이다.

TCP/IP의 application 계층이

osi에서는 application, presentation, session의 세 계층으로 나뉜다.

 

application 계층은 자유롭게 변경이 가능하며 대부분의 일은 이 계층에서 발생한다.

그 아래의 계층은 운영체제와 가까우며 쉽게 바뀌지는 않지만 지속적으로 변화하고 있는 부분이다.

 

계층별 식별자

데이터를 전송하면 각 계층 별로 식별자가 존재한다.

Application 계층에서는 웹&email&http&P2P를 식별하고,

Transport 계층에서는 port number를 통해 식별하고,

Network 계층에서는 ip address를 통해 식별한다.

 

ip는 각 인터페이스에게 각각의 ip가 부여된다.

ip 주소를 확인하는 방법은

맥에서는 ifconfig | grep inet, 윈도우에서는 ipconfig를 터미널에 작성하면

아래 사진과 같이 주소를 확인할 수 있다.

 

TCP의 상태 정보를 확인하는 방법은

윈도우 터미널에서 -tn | more를 입력하면

아래 사진처럼 주소 및 상태를 확인할 수 있다.

붉은 박스 안의 포트번호는 해당 웹이 암호화되어 있기 때문에 well-known으로 작성됨을 알 수 있다.

 

송신자 - 라우터 - 수신자

통신을 할 때 host로 가는 중 라우터를 거쳐야 하는데 우리가 가장 먼저 거치는 라우터는 공유기이다.

 

송신자 - 라우터 - *** - 라우터 - 수신자

맥 환경에서 터미널에 traceroute -n [경로]를 입력하면

해당 경로로 가기까지의 ip 주소와 경과 시간을 보여준다.

이때, 붉은 박스의 내용은 거쳐가는 라우터에 번호를 메긴 것이다.

푸른 박스 안의 내용은 ***로 나타나 있는데,

해당 부분은 라우터에서 해당 packet에 대해 차단하여 해당 정보가 보이지 않는다.

 

또한 경과 시간 부분을 보면 아래로 내려갈 수록 착실히 시간이 경과되다가

갑자기 spike처럼 튀는 구간이 존재하는데,

이 부분은 packet의 우선 순위에 따른 delay이다.

 

6번 라우터 이후 경과 시간이 급격하게 증가하는데

이 부분은 www.google.co.kr에 접속하기 위해 미국으로까지 신호를 전달하는 데에 걸린 시간이다. 

 

TTL(Time To Live)

우리는 도메인 주소를 통해 목적지만 알고 중간에 거쳐가는 라우터의 주소를 모른다.

하지만 traceroute는 어떻게 중간 라우터의 ip값을 알 수 있을까?

우리는 중간 라우트의 주소를 알기 위해서 중간 라우트에서 응답을 하게 해야 한다.

응답을 하게 하는 방법으로 중간에 오류를 일부로 발생시켜 나에게 응답하게 한다.

오류를 발생시키는 과정을 한 번 알아보자.

 

패킷은 부정확한 라우팅 테이블로 인해 라우터와 라우터 사이를 무한정으로 배회할 수 있다.

따라서 ip packet 안에 TTL(Time To Live)값을 넣어 해당 패킷이 유포되는 기간을 정할 수 있다.

즉, 해당 패킷이 네트워크 내에서 얼마나 오래 있었는지, 해당 패킷을 버려도 되는지를 판단할 수 있다.

 

패킷을 전송할 때 TTL 필드 내의 값에 숫자를 넣는다.

숫자는 자유롭게 넣을 수 있지만, 보통 255와 같은 큰 숫자를 넣어 문제 발생을 방지한다.

이후 라우터를 건너갈 때마다 해당 숫자를 1씩 감소시키고 해당 숫자가 0이 되면

해당 패킷은 폐기한 후 icmp 메세지를 나에게 다시 전송한다.

 

내 컴퓨터에서 라우터 정보 확인

터미널에서 라우터의 정보를 확인할 수 있다.

윈도우 환경에서 터미널에 netstat -rn 명령어를 입력하면 사진과 같이 라우터에 대한 정보가 뜬다.

(-rn이 라우터의 정보를 표시하라는 의미이다.)

목적지의 주소는 4byte로 구성되어 있고, routing 정보(목적지)가 적혀 있다.

패킷이 들어오면 routing table을 보고 목적지를 찾는다.

 

이때, 가장 상단에 위치한 0.0.0.0 주소는 자기 자신의 주소로,

mapping 되지 않은 경우에 사용되는 default값이다.

172로 시작하는 주소는 도커, 224로 시작하는 주소는 multicast이다.

 

위의 경우 개인 노트북 또는 컴퓨터이므로 연결된 라우터가 많지 않다.

하지만 통신사의 경우 주소의 개수가 어마어마하게 많고 그 처리량 또한 많다.

따라서 주소를 찾는 데에 짧은 시간이 소요되어야 하는데,

두 가지의 방법을 사용할 수 있다.

1. 순서대로 탐색하는 방법(브루트 포스)

2. 이진 탐색 (정렬 필요)

통신사와 같이 거대한 라우터에서는 주소를 찾는 알고리즘 구현이 매우 중요하다.

 

계층별 메세지 + 헤더

우리는 데이터를 전송할 때 헤더를 붙여 캡슐화를 한다.

각 계층 별로 사진과 같이 헤더를 붙인다.

 

패킷을 캡처해보면, 사진과 같이 각 계층별 헤더에 담긴 정보를 볼 수 있다.

 

인터넷 응용 프로토콜

인터넷의 응용은 각자 프로토콜이 필요하다.

하지만, 최근에는 라이브러리로 구현이 되어있어 추가적인 기능이 필요한 것이 아니라면 따로 구현할 필요가 없다.

• web: HTTP
• File transfer: FTP
• E-mail: SMTP, POP3

각각의 경우 위와 같은 라이브러리를 사용할 수 있으며,

최근에는 HTTP로 여러 가지 응용을 구현할 수 있다.

ex) 웹 메일, 웹 ssh, 웹 파일 전송, 웹 화상회의, 웹 비디오 등

 

인터넷 응용 개발

인터넷 응용 개발은 클라이언트와 서버 프로그램 개발(또는 P2P), 설치 및 운영을 할 수 있어야 한다.

프론트엔드, 백엔드, DevOps 직군을 포함하며 최근에는 웹 기반이 많다.

 

하지만 SW 개발자는 SW 테크니션과 같지 않은데

응용 뿐만 아니라 인터넷 시스템 소프트웨어가 근간이기 때문이다.

즉, 라우터, 단말기, 기지국 등을 잘 알기 위해서는 컴퓨터 시스템, 운영체제,

네트워크, 정보 보호 등의 깊이 있는 지식이 필수이다.

 

클라이언트 서버 구조

지금까지 우리는 클라이언트 서버의 구조에 대해 학습해왔다.

이들의 동작을 간단하게 정리해보자.

 

서버

서버는 항상 동작하고 있으며 요청이 들어오기 전까지는 대기하고 있다.

IP주소가 고정되어 있으며 도메인의 이름으로 해당 서버를 찾는다.

서버가 클러스터 형식으로 존재하여 여러 개의 요청을 동시에 받을 수 있다.

 

클라이언트

서버와 통신하는 부분으로 항상 통신하는 것이 아닌, 간헐적으로 통신을 한다.

IP 주소가 동적이고 클라이언트끼리 직접 통신하지 않으며

클라이언트 간의 통신은 항상 서버를 통해 이뤄진다.

 

P2P(Peer To Peer) 구조

P2P구조란 서버가 존재하지 않고 피어(클라이언트)들끼리 직접 통신하는 방법이다.

토렌트와 같은 사이트가 이러한 구조로 운영되고 있다.

P2P 구조를 사용하는 이유는 무엇일까?

 

보통 토렌트와 같은 사이트에서는 영상과 같은 용량이 큰 객체를 다운받는다.

따라서 서버 한 개의 용량으로 데이터가 큰 영상을 전송하기에는 힘들기 때문에

피어가 전 세계로 나누어져 파일을 공유할 때 직접적으로 성능을 향상시킬 수 있다.

 

이러한 방법은 연결이 불안하고 파일이 찾기 어렵다는 단점이 있다.

 

프로세스 간 통신

인터넷 통신은 프로세스 간의 통신으로 진행된다. (Inter-process comunication, IPC)

주로 소켓 API를 사용하며 따로 정해진 방식이 없으면 default로 IPC가 진행된다.

최근에는 쓰레드(thread) 간의 통신이 가능해져 단위가 더 작아졌다.

 

Server - Client 통신

서버와 클라이언트 간의 통신은 위와 같이 이뤄진다.

---

출처 및 참고

https://m.blog.naver.com/aka_handa/10081414226

https://www.cloudflare.com/ko-kr/learning/cdn/glossary/time-to-live-ttl/