모든 내용은 [윤성우 저, "열혈강의 TCP/IP 소켓 프로그래밍", 오렌지미디어] 를 기반으로 제 나름대로 이해하여 정리한 것입니다. 다소 부정확한 내용이 있을수도 있으니 이를 유념하고 봐주세요!
# 인터넷 프로토콜 기반 소켓
1) TCP(Transmission Control Protocol) : 연결지향형, "스트림 기반 소켓"
2) UDP(User Datagram Protocol) : 비연결지향형
# TCP(Transmission Control Protocol) : "데이터 전송과정의 컨트롤"의 뜻을 담고 있음
# TCP/IP 프로토콜 스택 : "인터넷 기반의 효율적인 데이터 전송(송수신)"이라는 문제를 계층화시켜서 해결
1) APPLICATION 계층(최상위계층)
2) TCP / UDP 계층
3) IP 계층
4) LINK 계층(최하위계층)
# 네트워크는
하드웨어적인 물리적 시스템(환경)을 기반으로 + 소프트웨어적인 알고리즘이 필요 => 다양한 분야의 전문가가 필요
# 프로토콜 계층화의 장점
1) 프로토콜 설계의 용이성
2) 표준화 작업을 통한 개방형 시스템(여러개의 표준을 근거로 설계된 시스템)의 설계가 가능
1. APPLICATION 계층
- 소켓을 통해 무엇인가를 만드는 과정에서 프로그램의 성격에 따라 클라이언트 / 서버 간의
데이터 송수신에 대한 약속(규칙)을 정하기 마련인데 -> 이를 APPLICATION 계층
- 대부분의 네트워크 프로그래밍이 이 프로토콜의 설계 및 구현의 상당부분임
2. TCP / UDP 계층
- IP 계층에서 알려준 경로정보를 바탕으로 데이터의 실제 송수신을 담당
- "전송(Transport) 계층"
- TCP : 신뢰성 있는 데이터 전송 담당, 그러나 TCP가 데이터를 보낼때 기반이 되는 프로토콜은
신뢰할 수 없는 프로토콜인 IP => 이상하지 않은가?
- IP는 하나의 데이터 패킷(데이터 전송의 기본단위) 전송하는 과정에만 중심을 두고 설계됨
- TCP는 데이터를 주고받는 과정에서 서로 주고받음을 확인하고, 분실된 데이터에 대해서 재전송해주는 역할
=> 이를 통해 신뢰성 확보. 즉, TCP는 확인절차를 거쳐 신뢰성없는 IP에 신뢰성을 부여한 프로토콜
3. IP 계층
- 목적지로 데이터를 전송하기 위해서 어떤 경로를 선택할지 해결하는 계층 => 이를 위해 사용하는 프로토콜이 IP
- 비연결지향적, 신뢰할수 없는 프로토콜(경로를 선택하긴 하지만, 그 경로가 일정하지는 않음)
- 데이터 전송 도중 경로상에 문제가 발생하면 다른 경로를 선택하는데,
이 과정에서 데이터가 손실되거나 오류가 발생하는 등의 문제가 발생해도 해결해주지 않음
4. LINK 계층
- 물리적인 영역의 표준화에 대한 결과
- 가장 기본이 되는 영역인 LAN, WAN, MAN 과 같은 네트워크 표준과 관련된 프로토콜을 정의하는 영역
# TCP 서버에서의 기본적인 함수호출 순서
1) socket : 소켓생성(그러나, 이것은 아직 서버소켓이 아님)
2) bind : 소켓주소 할당(IP, PORT)
3) listen : 연결요청 대기상태(이때 1에서 만든 소켓이 서버소켓(문지기역할)이 되며,
클라이언트의 연결요청을 대기시키는 연결요청 대기 큐가 생성됨)
(connect 호출 - 일반적)
4) accept : 연결허용(이때, 클라이언트 소켓과의 송수신을 위한 소켓이 "추가로 생성"됨,
클라이언트 소켓과 일대일 대응)
(connect 호출 - 일반적이진 않으나, 이때까지 accept는 블로킹됨)
5. read / write : 데이터 송수신
6. close : 연결종료
# 연결요청 대기상태로의 진입
- listen 함수가 호출되어야만 클라이언트는 연결요청을 위해 connect 함수를 호출 가능
(이전에 호출되면 오류 발생)
- listen 함수 호출을 통해 서버소켓(문지기 역할)이 생성되고, "연결요청 대기 큐"가 생성되면
비로소 "연결요청 대기상태"가 되는 것
- 연결요청 대기큐의 크기는 어디까지나 실험적 결과에 의존해서 결정하게 됨(서버의 성격에 따라 다르기 때문)
#include <sys/socket.h>
int listen(int sock, int backlog);
// -> 성공시 0, 실패시 -1 반환
- sock : 연결요청 대기상태에 두고자 하는 소켓의 파일 디스크립터,
이 함수의 인자로 전달된 디스크립터의 소켓이 서버 소켓(리스닝 소켓)이 된다.
- backlog : 연결요청 대기 큐(Queue)의 크기정보 전달,
이 크기정보만큼 클라이언트의 연결요청을 큐에 대기 시킬 수 있다.
# 클라이언트의 연결요청 수락
- listen 함수호출 이후 클라이언트의 연결요청이 들어오면, 들어온 순서대로 연결요청을 수락해야 함
- 연결요청을 수락하면 데이터 송수신이 가능해지므로, 이를 위한 소켓이 생성되어야 함
("서버소켓"말고 클라이언트 소켓과 데이터 송수신을 위한 일대일로 연결된 소켓이 추가로 생성되어야 함)
- accept 함수 호출로 이 소켓이 만들어지고, 이 소켓이 자동으로 클라이언트 소켓과 연결됨
- "연결요청 대기큐"에서 대기중인 클라이언트의 연결요청을 수락하는 함수가 바로 "accept"
- 만약 accept 함수가 호출되었을 때 연결요청 대기큐가 비어있다면, 대기큐에 요청이 들어올때까지
accept 함수는 반환하지 않음(블로킹)
#include <sys/socket.h>
int accept(int sock, struct sockaddr * addr, socklen_t * addrlen);
// -> 성공시 소켓의 파일 디스크립터, 실패시 -1 반환
- sock : 서버 소켓의 파일 디스크립터
- addr : 연결요청 한 클라이언트의 주소정보를 담을 변수의 주소값, 함수호출이 완료되면 인자로 전달된 주소의 변수에는 클라이언트의 주소정보가 채워진다.
- addrlen : 두번째 매개변수 addr에 전달된 주소의 변수 크기를 바이트 단위로 전달, 단 크기정보를 변수에 저장한 다음에 변수의 주소값을 전달한다. 함수 호출이 완료되면 크기정보로 채워져 있던 변수에는 클라이언트의
주소정보 길이가 바이트 단위로 계산되어 채워진다.
# TCP 클라이언트의 기본적인 함수호출 순서 : - "소켓의 생성", "연결의 요청"이 전부임
1) socket : 소켓생성
2) connect : 연결요청
3) read / write : 데이터 송수신
4) close : 연결종료
#include <sys/socket.h>
int connect(int sock, struct sockaddr * servaddr, socklen_t addrlen);
// -> 성공시 0, 실패시 -1 반환
- sock : 클라이언트 소켓의 파일 디스크립터
- servaddr : 연결요청 할 서버의 주소정보를 담은 변수의 주소값
- addrlen : 두번째 매개변수 servaddr에 전달된 주소의 변수 크기를 바이트 단위로 전달
# connect 함수가 호출되면 다음 둘 중 한가지 상황이 되어야 함수가 반환된다(함수호출이 완료된다)
- 서버에 의해 연결요청이 "접수"되었다. : 서버의 accept 함수호출이 아닌,
서버의 연결요청 대기큐에 등록된 것을 의미
- 네트워크 단절 등 오류상황이 발상해서 연결요청이 중단되었다.
=> 그러므로, connect 함수가 반환했더라도 당장에 서비스가 이뤄지지 않을수도 있음을 기억!
(연결요청 대기큐에 들어가있거나, 오류상황이 발생했을 수 있으므로)
# 클라이언트 소켓의 주소정보는 어디에?
- 클라이언트 소켓 역시 IP와 PORT의 할당이 반드시 필요하다.(서버소켓과 마찬가지로 주소정보 할당이 필요함)
- 서버소켓은 bind 함수를 통해 명시적으로 주소정보 할당을 한다.
- 클라이언트 소켓은
1) connect 함수가 호출될 때
2) 운영체제에서(커널에서)
3) IP는 해당 컴퓨터(호스트)의 IP로, PORT번호는 임의로 할당
=> 서버소켓과 달리 bind 함수 호출이 아니라, connect 함수호출시 자동으로 소켓에 IP와 PORT가 할당된다.
# Iterative 서버 : 연결요청을 하는 모든 클라이언트에게 서비스를 제공하는 서버
- 반복문으로 accept 함수를 반복호출하면 여러 클라이언트의 연결요청을 수락할 수 있음
- 그러나, 아직은 동시에 여러 클라이언트에 대해 서비스 제공은 불가
(프로세스와 쓰레드에 대해서 공부하고 나면 가능해짐)
- accept를 포함한 반복에서, close는 accept 함수 호출과정에서 생성된 소켓만을 대상으로 함
- 서버소켓에 대한 close는 반복문이 끝나면(모든 클라이언트에 대한 서비스가 종료되면) 호출함
# Iterative 에코 서버, 에코 클라이언트의 기본 동작방식
- 서버는 한 순간에 하나의 클라이언트와 연결되어 에코서비스를 제공
- 서버는 총 다섯개의 클라이언트에게 "순차적으로" 서비스를 제공하고 종료함
: 아직은 동시 서비스 제공은 불가능
- 클라이언트는 프로그램 사용자로부터 문자열 데이터를 입력받아 서버에 전송
- 서버는 전송받은 문자열 데이터를 클라이언트에 재전송, 즉 에코시킴
- 서버와 클라이언트 간의 문자열 에코는 클라이언트가 Q를 입력할 때까지 계속한다.
# echo_server.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#define BUF_SIZE 1024
void error_handling(char *message);
int main(int argc,char *argv[])
{
int serv_sock, clnt_sock;
char message[BUF_SIZE];
int str_len, i;
struct sockaddr_in serv_adr, clnt_adr;
socklen_t clnt_adr_sz;
if(argc!=2) // 실행파일의 경로 / PORT번호 를 입력 받아야 함
{
printf("Usage : %s <port>\n",argv[0]);
exit(EXIT_FAILURE);
}
serv_sock=socket(PF_INET,SOCK_STREAM,0); // TCP 소켓 생성
if(serv_sock==-1)
error_handling("socket() error");
// 서버 주소정보 초기화
memset(&serv_adr,0,sizeof(serv_adr));
serv_adr.sin_family=AF_INET;
serv_adr.sin_addr.s_addr=htonl(INADDR_ANY); // INADDR_ANY로 IP정보를 초기화 했음을 유의!
serv_adr.sin_port=htons(atoi(argv[1]));
// 주소정보를 기반으로 주소할당
if(bind(serv_sock, (struct sockaddr*)&serv_adr, sizeof(serv_adr))==-1)
error_handling("bind() error");
// 이때 소켓이 서버소켓이 되고, 연결대기큐 생성
// 클라이언트의 연결요청이 허가됨
if(listen(serv_sock, 5)==-1)
error_handling("listen() error");
clnt_adr_sz=sizeof(clnt_adr);
for(i=0;i<5;++i) // 5번의 클라이언트의 연결요청을 수락하기 위함임
{
clnt_sock=accept(serv_sock,(struct sockaddr*)&clnt_adr,&clnt_adr_sz);
// 연결대기중인 클라이언트에 대해 연결요청을 수락
// 이때 클라이언트와 데이터 송수신을 위해 새로운 소켓이 생성됨
if(clnt_sock==-1)
error_handling("accept() error");
else
printf("Connected client %d\n",i+1);
while((str_len=read(clnt_sock,message,BUF_SIZE))!=0) // 클라이언트로부터 수신한 문자열이 있을때에
write(clnt_sock,message,str_len); // 그 문자열을 그대로 에코
// 클라이언트에서 널문자를 포함하지 않고 전송했음을 유의
close(clnt_sock); // 에코 서비스를 제공하고 소켓을 닫음
}
close(serv_sock); // 모든 클라이언트에 대한 서비스를 마치고 서버소켓을 닫음
return 0;
}
void error_handling(char *message)
{
fputs(message,stderr);
fputc('\n',stderr);
exit(EXIT_FAILURE);
}
# echo_client.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdbool.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#define BUF_SIZE 1024
void error_handling(char *message);
int main(int argc,char *argv[])
{
int sock;
char message[BUF_SIZE];
int str_len;
struct sockaddr_in serv_adr;
if(argc!=3) // 실행파일의 경로 / IP / PORT 번호를 입력받아야 함
{
printf("Usage : %s <IP> <port>\n",argv[0]);
exit(EXIT_FAILURE);
}
sock=socket(PF_INET,SOCK_STREAM,0); // TCP 소켓 생성
if(sock==-1)
error_handling("socket() error");
// 서버 주소정보의 초기화
memset(&serv_adr,0,sizeof(serv_adr));
serv_adr.sin_family=AF_INET;
serv_adr.sin_addr.s_addr=inet_addr(argv[1]);
serv_adr.sin_port=htons(atoi(argv[2]));
// 주소정보를 기반으로 서버에 연결요청
// 이 때, 명시적인 클라이언트 소켓이 되며 주소정보를 할당함
if(connect(sock,(struct sockaddr*)&serv_adr,sizeof(serv_adr))==-1)
error_handling("connect() error!");
else
puts("Connected................");
while(true) // q나 Q를 입력할 때까지 문자열 전송
{
fputs("Input message(Q to exit): ",stdout);
fgets(message,BUF_SIZE,stdin);
if(!strcmp(message,"q\n") || !strcmp(message,"Q\n"))
break;
write(sock,message,strlen(message)); // 서버로 문자열(널문자 포함하지 않고) 전송
str_len=read(sock,message,BUF_SIZE-1); // 서버에서 에코한 문자열 수신
// 단, 서버에서 널문자를 제외하고 보냄을 유의
message[str_len]='\0'; // 서버에서 수신한 문자열 맨 뒤에 널문자 추가
printf("Message from server: %s",message);
}
close(sock);
return 0;
}
void error_handling(char *message)
{
fputs(message,stderr);
fputc('\n',stderr);
exit(EXIT_FAILURE);
}
# 에코 클라이언트의 문제점
echo_client.c 중 일부
write(sock,message,strlen(message)); // 서버로 문자열(널문자 포함하지 않고) 전송
str_len=read(sock,message,BUF_SIZE-1); // 서버에서 에코한 문자열 수신
// 단, 서버에서 널문자를 제외하고 보냄을 유의
message[str_len]='\0'; // 서버에서 수신한 문자열 맨 뒤에 널문자 추가
printf("Message from server: %s",message);
위 코드는 다음과 같은 잘못된 가정이 존재한다.
"read, write 함수가 호출될 때마다 문자열 단위로 실제 입출력이 이뤄진다."
=> 그러나 TCP의 특징 중 하나는 "데이터의 경계가 존재하지 않는다."
=> 따라서, 위의 가정은 잘못된 가정임
[출처] : 윤성우 저, "열혈강의 TCP/IP 소켓 프로그래밍", 오렌지미디어
'Programming > 열혈 TCP, IP 소켓 프로그래밍(저자 윤성우)' 카테고리의 다른 글
Ch 05. TCP 기반 서버/클라이언트 2 (0) | 2020.08.06 |
---|---|
Ch 04. 내용 확인문제 (0) | 2020.08.06 |
Ch 03. 내용 확인문제 (0) | 2020.08.05 |
Ch 03. 주소체계와 데이터 정렬 (0) | 2020.08.05 |
Ch 02. 내용 확인문제 (0) | 2020.08.04 |