[4주차] TIL - 230616

오늘 공부한 내용

☁️

[merge 답변] c언어에서 레코드를 무효화시키는 함수 동작분석 및 개선

https://lamong.tistory.com/36

---

🫠(개인공부)

데이터 통신 기말정리(12~14장)

 

12장

 

소켓의 주소

일반 프로그래밍 환경에서는 AF_UNIX와 AF_INET의 소켓 주소 체계를 많이 사용한다. AF_UNIX로 표시되는 유닉스 주소 체계는 한 호스트 내부에서 실행되는 프로세스 사이의 통신을 지원하고, 사용하는 주소 체계는 파일 시스템의 경로명을 기반으로 한다. 서로 다른 호스트에서 실행되는 프로세스 사이의 통신을 지원하려면 인터넷 주소 체계 방식인 AF_INET을 사용한다. 소켓 주소는 소켓 시스템 콜을 사용하는데 의미는 같으나 형식이 다른 구조체들을 함수 매개변수 하나로 수용하는 것은 문법적으로 불가능하다. 따라서 여러 소켓 구조체를 일반 구조체 하나로 정의해야 한다.

 

소켓의 서비스 유형

SOCK_STREAM은 연결형 서비스를 제공할 때 사용하고, SOCK_DGRAM은 비연결형 서비스에서 사용한다. SOCK_RAW는 일반 네트워크 응용 프로그램 개발에서는 자주 사용되지 않으며, IP 프로토콜을 직접 사용한다.

 

INADDR_ANY

개발된 프로그램이 여러 컴퓨터에서 실행되는 경우, 각 실행 파일에 개별 호스트의 IP 주소를 지정하여 컴파일하기는 현실적으로 불가능하다. 이와 같은 상황을 고려해 INADDR_ANY라는 호스트 주소 표기 방법을 제공한다. 이는 프로세스가 실행되는 로컬 호스트 자체를 의미하기 때문에 프로세스가 실행되는 호스트의 IP 주소로 자동 대체된다. 결과적으로 동일한 프로그램을 여러 컴퓨터에서 실행할 때마다 주소를 변경하고 재컴파일하지 않아도 된다.

 

주소 변환(바이트 순서)

컴퓨터마다 정수형 데이터를 저장하는 기억 장소 공간의 바이트 순서가 다를 수 있다. 이 차이를 극복하기 위해 네트워크 바이트 순서라는 전송 문법의 데이터 유형이 필요하다. 데이터를 전송하기 전에 개별 컴퓨터의 바이트 순서를 네트워크 바이트 순서로 변환해야 한다. htonl()과 htons() 함수는 데이터를 수신할 때 컴퓨터 바이트 순서를 네트워크 바이트 순서로 변환하는데, ntohl()과 ntohs() 함수는 반대로 네트워크 바이트 순서를 개별 컴퓨터의 바이트 순서로 변환한다.

 

연결의 설정

연결형 서비스를 지원하는 서버 프로세스가 클라이언트의 연결 요청을 받으려면 accept() 함수에서 대기해야 한다. 즉, 클라이언트-서버 환경에서 서버 프로세스는 accept()함수를 실행해 클라이언트의 요청을 기다리고, 클라이언트 프로세스의 connect() 요청이 발생하면 연결이 설정된다.

 

주소 변환(표시 형식)

인터넷 주소는 십진수를 사용해 표기하는데 컴퓨터 내부에서는 32비트 크기의 이진수 방식으로 처리하므로 십진수와 이진수 표기를 변환하는 기능이 필요하다. inet_addr() 함수가 십진수 표기 형식을 32비트 인터넷 주소로 변환하고, inet_ntoa() 함수는 그 반대의 기능을 수행한다.

 

클라이언트-서버 모델

클라이언트-서버 모델에서 서비스를 제공하는 프로그램을 서버 프로세스, 서버와 연결을 시도하여 서비스를 제공받는 프로그램을 클라이언트 프로세스라 한다. 서버 프로세스는 다수의 클라이언트에 공개되는 Well-known 포트로 자신의 소켓 주소를 설정한 후에, 클라이언트의 연결 요청을 기다린다. 클라이언트 요구에 따라 연결이 설정되면 서버 프로세스가 제공하는 서비스가 시작된다.

 

비연결형 서비스

비연결형 서비스에서는 connect()와 accept() 함수로 연결을 설정하는 과정이 생략되며, 데이터 송수신을 위한 send(), recv() 함수 대신 sendto(), recvfrom() 함수를 사용한다. 비연결형 서비스에서는 전송 데이터마다 송신자의 소켓 주소를 함께 전송한다.

 

 

13장

 

웹 서비스

웹 브라우저는 80번으로 지정된 웹 서버의 TCP 포트 번호를 이용해 서버와 연결을 시도한다. 웹 서버와 연결이 설정되면, 클라리언트의 정보 요구에 대해 서버가 웹 문서를 회신하는 방식으로 응답한다. 서버가 전송한 문서의 내용은 클라이언트의 웹 브라우저를 통해 사용자 화면에 표시된다. 클라이언트와 서버 사이의 연결은 사용자의 정보 요구가 발생할 떄마다 새로운 연결을 설정하고 애제하는 과정을 반복한다.

 

URL

클라이언트가 웹 서버를 지칭할 때 사용하는 주소를 뜻하며, 사용하는 프로토콜, 연결하고자 하는 서버의 호스트 이름, 서버 내부의 파일 경로명이라는 새 부분으로 표현된다

 

APM

PHP는 유닉스나 리눅스 환경에서 주로 사용되며, 웹 서버 프로그램인 Apache와 데이터베이스 기능을 지원하는 MySQL이 서로 연동해 동작한다. 이 세가지를 통칭해 APM이라 부른다. PHP는 HTML언어의 기능을 보완하는 역할을 한다. 즉, HTML언어는 웹 문서를 작성하는 데 한계가 많다. 이를 보완하려고 PHP 언어가 개발되었으며, HTML 문서 내부에 PHP 코드를 추가하는 형식으로 사용한다.

 

HTML

HTML은 웹 브라우저의 어느 위치에 어떤 데이터를 어떤 모양으로 표시하는지를 나타낸다. 즉, 화면의 출력 형식을 기술하는 언어이다. HTML로 작성한 문서는 서버에 보관되고, 클라이언트는 이 문서의 내용을 회신받아 웹 브라우저에 출력한다. 출력 결과는 HTML로 기술된 방식을 따라 웹 브라우서는 HTML을 해석하는 프로그램이라 할 수 있다.

 

HTTP

HTTP는 분산 히이퍼미디어 환경에서 빠르고 간편하게 데이터를 전송하는 프로토콜이다. HTTP는 80번 포트를 사용하도록 정의되어 80번 포트에서 대기하고, 클라이언트는 TCP를 사용해 연결을 설정한다. 사용자는 요청 자원을 가리키는 URL 주소에 사용할 프로토콜을 표현한다. 즉, URL 주소의 첫 번째 부분을 사용해 서비스 유형을 표현한다.

 

CGI

사용자가 입력하는 정보를 처리하려면 CGI 기능이 필요하다. CGI는 새로운 언어의 개념이 아니라 c, c++, 쉘, 펄 등과 같은 언어로 작성되어 서버에서 실행되는 프로그램.

 

 

14장

 

DNS 서비스

인터넷에서 연결된 모든 컴퓨터는 32비트 숫자로 구성된 고유의 IP 주소를 부여받는다. 이 숫자는 IP 프로토콜의 패킷 속에 기록되어 적절한 경로를 선택하는 길잡이 역할을 한다. 초기 인터넷 환경에서는 일반 사용자에게 문자로 된 호스트 이름을 지원하려고 호스트 파일이라는 텍스트 문서를 만들어 보급하는 원시적인 방법을 사용했다. 인터넷의 규모가 커지면서 더 이상 수작업으로 관리할 수 없게 되었는데, 이로인해 DNS 시스템이 탄생했다. DNS는 계층 구조를 지원하는 도메인 기반의 주소 표기 방법을 위한 분산 데이터베이스 시스템으로, 기본 목적은 도메인 이름에서 IP 주소를 얻는 것이다.

 

DNS 구성요소

• 네임 스페이스: 트리 구조의 네임 스페이스를 비롯해 데이터에 대한 이름 관련 규칙을 정의한다. 도메인 네임 스페이스의 트리에 연결된 호스트는 자원 레코드라는 정보 집합체로 표현된다
• 네임 서버: 도메인 트리 구조와 트리에 보관된 정보 집합체를 관리하는 프로그램
• 해석기: 네임 서버로부터 클라이언트의 요청 정보를 얻어내는 프로그램이다. 최소 하나 이상의 네임 서버와 접촉하며, 네임 서버의 정보를 이용해 응용 프로그램의 질의에 응답한다.

네임 스페이스

네임 스페이스는 계층적인 트리 구조를 지원한다. 도메인 이름은 최하위에 있는 호스트의 레이블을 맨 왼쪽에 두고, 상위 노드로 이동하면서 점으로 구분한 레이블 이름을 연속으로 붙인다. 도메인이라는 명칭은 도메인 네임 스페이스에 있는 하부 트리 전체를 의미하며, 해당 도메인의 이름은 하부 트리의 맨 상위에 있는 호스트의 도메인 이름이다.

 

자원 레코드

DNS 서비스는 이름과 주소 정보를 저장하기 위한 데이터베이스이므로 레코드 개념이 필요하다. 이를 위해 자원 레코드라는 개념을 사용해 DNS 데이터를 저장한다. 트리에 연결된 각 호스트는 자원 레코드와 관계되며, 네임 서버의 데이터베이스는 자원 레코드로 구성된다. 따라서 DNS 네임 서버가 DNS 클라이언트인 해석기에 반환하는 데이터는 자원 레코드가 된다.

 

네임 서버와 해석기

DNS 서비스는 클라이언트-서버 구조로 설계되었다. 도메인 이름과 호스트 주소의 변환 전ㅇ보를 원하는 네트워크 응용 프로그램은 해석기라 불리는 DNS 클라이어느에 정보 제공을 요청한다. 해석기는 가장 가까운 네임 서버와 접촉해 정보 제공을 요청하고, 해당 서버에 정보가 없으면 다른 네임 서버와 접촉해 정보를 찾는 과정을 반복함.

 

DNS 메시지

DNS 프로토콜을 사용하는 호스트는 DNS 데이터를 요청하거나, 반대로 응답할 때 DNS 메시지를 전송한다. DNS 프로토콜은 DNS 요청을 하는 호스트와 요청에 대한 응답 기능을 수행하는 호스트 사이의 상호 동작을 지원하기 위해 질의 메시지와 응답 메시지를 정의한다. DNS 요청이 필요하면 DNS 메시지에 그 내용을 기록한다. Header를 포함해 모두 다섯 부분으로 구성된 DNS 메시지에서 Question 필드는 네임 서버에 요청하는 문의 사항을 의미하므로 질의 레코드를 사용한다. 나머지 Answer, Authority, Additional 필드는 자원 레코드를 사용한다.

 

UDP 프로토콜

해석기와 네임 서버는 53번 포트를 기본으로 사용해 UDP의 최대 전송 크기인 512 바이트를 초과하는 전송 요구를 처리하기 위해 TCP를 사용하기도 한다. TCP를 사용할 떄도 DNS 메시지 전송은 53번 포트를 사용한다. TCP를 사용할때는 2가지를 고려해야 하는데, 응답 메시지가 512 바이트보다 크다는 사실을 해석기가 미리 인지하는 경우로, 이땐 처음부터 TCP 연결을 사용한다. 다음은 해석기가 사전에 인지하지 못한 상태에서 UDP를 사용하는 경우로 응답 메시지의 헤더에 있는 TC 플래그가 1로 지정되니, 해석기가 TCP 연결을 설정해 올바른 응답을 요청할 수 있다.