지금까지 내가 겪은 네트워크는 Client-Server 구조로 요청하면 응답해주는 형식이었다.
최근 블록체인을 공부하다보니 이쪽은 전혀 다른 P2P(peer-to-peer) 구조였다.
1. Client-Server
- 서버: 항상 운영되는 호스트 / 고정 IP 주소 / 확장 대비 데이터 센터
- 클라이언트: 서버와 통신 / 필요시 서버와 접속 / 유동 IP 주소 사용 / 클라이언트 간 통신 없음
2.
3. P2P(peer-to-peer)
- 항상 운영되는 호스트 없음
- 종단 시스템 간 통신 가능
- 피어는 다른 피어에게 서비스를 요청하거나 제공할 수 있음
- 자가 확장: 새로운 피어는 서비스 요청과 제공 모두 가능
- 피어는 필요시 접속되며 IP 주소 변경됨 (관리 어려움)
4. 프로세스 간 통신
- 프로세스 = 호스트에서 실행되는 프로그램
- 다른 호스트에서 운영되는 프로세스는 메시지를 교환하여 통신
- 클라이언트 프로세스: 통신을 시작하는 프로세스
- 서버 프로세스: 연결을 기다리는 프로세스
- P2P 구조의 애플리케이션은 클라이언트 프로세스와 서버 프로세스 속성 모두 가짐
구글링 하다보니 대부분 내용도 비슷하고 그림도 비슷하다. (내가 가져온 그림도)
더 깊히 알아보고 싶지만 예제를 가져다 놓는거 아니면 이해를 돕기도 어렵고 그 내용 또한 빙산의 일각이기에
소켓에 대해서 제대로 알아보기로 했다.
5. Socket(소켓)
프로세스간 메시지를 송수신할 때 출입문과 같은 역할로 사용됨. (통신 접속점)
- 송신 프로세스는 메시지를 문밖으로 보내고, 문밖에 있는 전송 하부구조에 의존하여 수신 프로세스가 존재하는 호스트의 소켓에 메시지를 전달
- 소켓은 응용 계층과 전송 계층 사이에 존재
- TCP/IP를 이용할 수 있도록 하는 API(Application Programming Interface)
위 그림은 소켓에 대해 OSI(Open System Interconnection(개방형 시스템간 상호 접속)) 계층과 연계하여 설명해준다.
왼쪽은 TCP 통신, 오른쪽은 UDP 통신
그림에 대해 설명하기 전에 TCP와 UDP에 관한 내용 먼저
6. 인터넷 전송계층 프로토콜 서비스
6.1. TCP
- 송수신 간 신뢰할 수 있는 전송
- 연결 기반: 클라이언트와 서버간에 사전 설정 필요
- 흐름 제어: 송신자의 수신 역량은 수신자의 수신 역량을 초과할 수 없음
- 혼잡 제어: 네트워크 혼잡시 송신자는 송신량을 조절
- 미제공 서비스: 타이밍, 처리율 보장, 보안 등
6.2. UDP
- 송수신 간 신뢰할 수 없는 전송
- 비연결 기반: 클라이언트와 서버간에 사전 설정 불필요
- 미제공 서비스: 신뢰성, 흐름 제어, 혼잡제어, 타이밍, 처리율 보장, 보안 등
7. TCP 보안
- TCP와 UDP는 모두 암호화가 없다
- 평문 패스워드가 평문으로 인터넷을 통해 암호화 없이 그대로 전송된다.
- SSL: TCP에 보안 기능을 추가해 준다. 데이터 정합성, 종단간 인증
- 응용 계층에서 SSL 설정: 애플리케이션은 SSL 라이브러리를 사용하여 TCP를 통해 통신
- SSL Socket API: 평문 패스워드가 암호문으로 변경되어 인터넷을 통해 전송
Application은 누군가 소켓을 이용해 만든 프로그램이고 sd는 socket descriptor, fd는 file descriptor이다.
여기서 처음 등장한 descriptor들은 우리말로 '기술자' 엔지니어가 아니라 '~을 기술하다' 할때 그 기술이다.
이 descriptor들은 우리가 만든 프로그램이 살아 움직이는 상태인 프로세스에서 열린 파일과 소켓의 목록을 관리하는 0이 아닌 정수(unsigned int!)이다.
좀 더 자세하게는.. file descriptor는 파일에 접근할때 사용하고, socket descriptor는 패킷 송수신 시 사용한다. 그리고 descriptor들은 하나의 프로그램에서만 유일하게 배정된다. (지역성을 가짐)
유닉스와 리눅스 운영체제에서는 모든 리소스를 file로 취급하고 처리하기 때문에 한 테이블로 두고 관리한다.
그런데 윈도우 운영체제에서는 소켓과 파일을 서로 다른 리소스로 구분한다고 한다.
(윈도우에서는 file descriptor를 HANDLE 이라고 한다)
sd가 socket descriptor이니 여기서 나온 화살표를 따라가면 socket을 가리키고 있다.
그리고 또 다시 연결선을 따라가보면 포트 번호가 있고 TCP와 UDP가 있다.
소켓이 프로세스에서 보낸 메세지를 전송 계층으로 전달해줬다.
이어서 가보면 IP와 IP주소를 거쳐 네트워크로 빠져나간다.
조금 더 자세히 들어가기 전 주소 운용 체계와 애플리케이션 계층 프로토콜 정의를 알아봄.
8. 주소 운용 체계
고유 주소인 IP 주소 + 포트 번호
9. 애플리케이션 계층 프로토콜 정의
- 교환 메시지 형식(req, res) => (request, response)
- 메시지 문법: 메시지에 포함된 필드, 필드 간 구분법
- 메시지 의미: 필드가 의미하는 내용
- 프로세스는 언제, 어떻게 메시지를 송수신할 것인가에 대한 규칙 구현
- 공개된 프로토콜: RFC에 정의, 상호 작용을 고려(http, smtp 등)
- 독점 프로토콜: skype 등
- 4가지 기준으로 전송 서비스 종류가 나뉨
- 데이터 정합성: 100% 신뢰하는 데이터 전송 필요(ex 파일전송)
- 시간 민감도: 낮은 지연 시간 필요(인터넷 전화, 게임)
- 처리율: 최소 처리율, 유연한 처리율 필요(영상, 음성)
- 보안: 암호화, 데이터 정합성 등
위에서 얘기한 descriptor에 대해 좀 더 자세한 내용이다.
위의 OSI 계층 그림에서 Application 1의 sd=5는 파일이나 소켓의 정보를 저장하는 구조체에 대한 포인터들을 담고있는 descriptor table의 index 번호를 말한다.
위 descriptor table에서 index가 5인 포인터에서 이어진 빨간 화살표를 따라가면 소켓의 정보를 담고 있는 구조체를 볼 수 있다.
저게 전부는 아니겠지만 대략적으로 구조체에 포함되는 정보들이다.
위 그림의 descriptor table에서 index를 3부터 시작한 이유는
기본적으로 리눅스에서 descriptor table index 0, 1, 2는 각각 표준 입력, 출력, 에러로 사용하기 때문이다.
사용자가 개설하는 소켓, 파일은 3번부터 사용한다.
이론적인 부분은 이 정도를 알고 구현하면서 더 배워나가면 될것같다.
[참조]https://m.blog.naver.com/dbal12365/221973737402, https://owljoa.postype.com/post/1546503
