- 애플리케이션 계층 - 인터넷 사용자에게 서비스 제공
- 커뮤니케이션은 논리적 연결을 사용해서 제공 (메시지 주고바을 때 논리적 연결 사용)
peer-to-peer 패러다임
- 항상 서버 있는 것 X
- 양단간 임시적 소통
- 관리는 어려우나 확장성이 좋고 분산성이 높음
믹스 패러다임
- 클라이언트 서버 패러다임 : 클라이언트가 서버에 요청 → 서버가 클라이언트에 응답
- P2P ; 클라이언트가 다른 클라이언트로 정보 공유 가능
클라이언트 서버 패러다임
- 서버
- 영구적인 IP 주소
- 클라이언트 요청에 대해 응답 서비스
- 클라이언트
- 서버에 요청 보냄
API (Application Programming Interface)
- TCP/IP의 하위 4계층에 연결을 생성하고 데이터를 주고 받고 연결을 끊으라는 명령의 집합
- 소켓 인터페이스
- 운영체제 - 애플리케이션 계층 사이의 소통을 제공하는 명령어 집합
- 터미널이나 파일처럼 행동하지만 물리적인 것은 아님
- 애플리케이션 프로그램에 의해 생성하고 사용하는 자료 구조
- 운영체제의 전송, 네트워크, 데이터링크, 물리 계층을 소켓 인터페이스를 통해 애플리케이션 계층과 소통
- 소켓
- 클라이언트와 서버 프로세스 사이의 소통에 사용됨
- 클라이언트는 소켓이 요청을 전달하고 응답을 준다고 인식
- 서버는 소켓이 요청을 가지고 있고 응답을 필요로 하는 개체로 인식
- 소켓 주소
- 클라이언트 서버 패러다임에서 소통은 두 소켓 간 소통이므로 소켓 두개의 소켓 주소 필요
- local 주소 : 송신지
- 현재 컴퓨터에 실행중인 운영체제가 제공하는 IP 주소
- 포트 넘버는 서버가 실행을 시작하면 그 때 결정됨
- remote 주소 : 수신지
- 클라이언트가 서버에 연결을 시도하면 결정됨
- 하나의 클라이언트에 하나의 remote 소켓 주소 할당
- local 주소 : 송신지
- IP 주소 32 bits + port number 16bits
- 전송계층에서 사용하는 프로토콜 - UDP
- connectionless, ureliable, datagram
- 데이터그램 = 패킷로 캡슐화된 독립적 메시지 개체
- 메시지가 작은 경우, 안정성보다는 속도가 중요한 경우 사용
- connection-oriented reliable, byte-stream
- 연결을 생성하는 패킷을 교환하여 양 단간 논리적 연결 먼저 생성
- Handshaking 프로세스 : 교환할 패킷의 사이트를 포함하여 양 단간 파라미터 설립
- 메시지가 길고 안정성이 중요한 경우 사용 FTP (File Transfer)
- UDP + TCP
- TCP : 연결 지향, 안정성
- UDP : 데이터그램
- 웹 페이지 (정보가 담긴 문서) 저장소
- 목적 : 연결된 문서 찾기 + 다양한 웹 서비스 제공
- 전세계에 분산
- 연관된 문서간 연결
- 서버가 제공하는 서비스에 클라이언트가 브라우저를 이용해서 접근
- 웹 클라이언트 (브라우저)
- 컨트롤러 + 클라언트 프로토콜 + 인터프리터
- 웹 서버
- 서버는 웹 페이지들을 저장하고 있음
- 요청이 도착하면 그에 해당하는 문서 (웹 페이지)로 응답
- 캐시에 요청된 파일 저장 → 효율성 개선
- 멀티쓰레딩, 멀티프로세싱을 통해 효율성 높임
- URL (Uniform Resource Locator)
- 웹 페이지 고유식별자
- 프로토콜 + 호스트 IP 주소/이름 + 포트 넘버 (16 비트) + 경로(운영체제 기반의 파일 경로 및 이름)
- 웹 문서
- 정적 문서
- 동적 문서 (브라우저가 문서를 요청하면 웹이 생성하는 분서, 서버로부터 데이터
- 웹으로부터 웹 페이지를 얻기 위해 서버 클라이언트 패러다임을 어떻게 정의해야 하는지에 대한 통신 규약
- 클라이언트는 요청을 보내고 서버는 응답을 반환
- 서버는 80 포트 사용 클라이언트는 임시 포트넘버 사용
- HTTP - TCP 사용
- nonpersistent connection : 각 요청과 응답 마다 TCP 연결을 생성
- 클라이언트가 TCP 연결을 열고 요청을 보냄
- 서버가 응답을 보내고 연결을 닫음
- 클라이언트가 EOF 마크를 마주치지 전까지 데이터를 읽고 연결을 닫음
- persistent connectio : 응답을 보낸 후 에 추가적인 요청을 기다리며 연결을 유지하는 것
- 서버는 클라이언트 요청이 오거나 타임아웃되면 연결 끊기 가능
- 서버는 각 응답에 포함된 데이터의 길이를 보냄
- 시간과 자원이 절약되는 연결 방식
- 요청 메시지 포맷
- 첫번째 라인 (request line) : method + URL + version
- 다음 라인 : zero / request header lines : 요청 추가 정보, 보내는 요청에 대한 주석, POST, PUT을 위한 파일을 바디에 삽입
- ** If-Modified-Since : ... / 하면 ... 이후에 수정된 적이 있다면 GET하는 조건 요청 가능 (헤더 라인에 추가 ) → 304 응답 받으면 수정되지 않았음을 응답
- 응답 메시지 포맷
- status line
- 100: informational code
- 200 : 요청 성공 상태
- 300 : 클라이언트를 다른 URL로 리다이렉트
- 400 : 클라이언트 측 오류
- 500 : 서버 측 오류
- header line : zero or 추가 정보
- blank line (헤더와 바디 사이의 빈칸)
- body : Date, Upgrade, Set-Cookie, Content-encoding, Content-length, Type, Last modified, Accept range 등
- status line
- 클라이언트에 대한 정보를 임시적으로 서버가 저장하기 위한 기술
- 서버는 응답에 클라이언트에 대한 정보를 포함하는 쿠키를 포함시키고 클라이언트에게 보냄
- 클라이언트는 쿠키 디텔토리에 쿠키를 저장함
- 클라이언트가 서버에 요청을 보내면 브라우저는 쿠키 디렉토리를 먼저 확인해서 해당 서버로부터 받은 쿠기가 있는지 확인하고 있다면 쿠키를 요청에 포함시켜 보냄
- 서버가 요청을 받으면 이전에도 요청을 보냈던 클라이언트임을 인지함
- 쿠키 내용은 브라우저에서 절대 읽어질 수 없고 오직 서버에 의해 만들어지고 서버만 읽을 수 있음
- HTTP는 프록시 서버를 지원함
- 프록시 서버란, 최근 요청에 대한 응답의 복본을 저장하는 서버
- HTTP 클라이언트는 프록시 서버에 요청을 보냄
- 프록시 서버는 캐시를 확인함
- 캐시에 응답이 저장되어 있지 않다면 프록시 서버는 해당하는 서버에 요청을 조냄
- 프록시 서버로 응답이 돌아오면 이를 저장하고 다른 클라이언트가 요청하면 저장해 둔 응답을 보내줌
- 프록시서버는 기존 서버의 부하, 트래픽을 줄이고 지연시간을 개선
- 프록시 서버는 주로 클라이언트 사이트에 위치함
- 프록시 서버의 계층 구조
- 클라이언트 컴퓨터도 프록시 서버를 사용함 (서버보다는 작은 용량) , 클라이언트에 의해 자주 발생하는 요청에 대한 응답을 저장
- 프록시 서버는 LAN 컴퓨터에 설치되어 부하를 줄일 수도 있음
- 많은 고객을 가진 ISP는 프록시 서버를 설치해 ISP 네트워크로 들어오고 나가는 부하를 줄임
- 바이너리 프로토콜
- 요청 및 응답의 오버헤드 줄임
- 문자열 스트림 → 특정 바이너리 엔토딩 포맷
- 헤더 필드 압축 가능
- headers frae + data frame
- 스트림과 멀티플렉싱
- 각 요청 응답 쌍 - 고유한 아이디 = stream을 가짐
- 클라이언트는 각 요청을 구별할 수 있거 요러개의 요청과 응답을 병렬적으로 interleave할 수 있음
- 스트림 priority
- 클라이언트는 서버에 자원 우선순위에 따라 요청 가능
- 예를 들어 html, css, js 파일을 이미지 파일보다 우선해서 렌더링 하도록 요청 가능
- server push
- 서버는 클라이언트의 자원 요구사항에 대한 사전 지식을 가질 수 있음
- HTTP/1은 매 요청마다 handshake를 해야 한다는 단점
- HTTP/2는 전체적으로 지연시간을 줄였지만 TCP는 원래 순서대로 패킷을 전달하고, 연결 내에서 독립적인 스트림을 인지하지 못해서 패킷이 손실되거나 정체될 수 있는 문제가 있음
- HTTP/3는 TCP보다 개선된 전송 프로토콜을 사용해서 2의 문제를 개선해야 한다. = QUIC 등장 (Quick UDP Internet Protocol)
- TCP/IP에 의해 제공되는 표준 프로토콜
- 2개의 병렬적 TCP connection 사용/ 제어 정보를 보내기 위한 control connection, 파일 전송을 위한 data connection
- 파일 복본을 전달하기 위한 것
- 사이즈 크고 다른 포맷을 사용하는 파일을 전송할 떄 HTTP 보다 좋은 선택
- FTP 서버 컴포넌트
- control 프로세스 → control connection , FTP 세션을 시작하면 연결이 생성되어 전체 세션 동안 연결이 유지됨
- data transfer 프로세스 → data connection , 전송하려는 파일을 포함한 명령어 마다 열어서 사용하고 파일이 전송되면 닫힘
- 서버 사이트 well-known 포트 : 20
- 핵심
- 서버→ 클라이언트 파일 찾기
- 클라이언트 → 서버 파일 저장
- 서버 → 클라이언트 디렉토리 리스팅
- 단 방향 트랜잭션
- 양단간 사용자들이 매개 서버를 통해 메시지 교환
- 컴포넌트
- User agent 두개 : 메시지 구성, 읽기, 응답, 포워딩, 메일 박스 관리
- message trasnfer agent 두 쌍
- message access agent 한 쌍
- 이메일 주소 : local part @ domain name
- sender(클라이언트/UA) - 메일 서버 (서버 클라이언트) - 인터넷 - 메일 서버 (서버 클라이언트) - reciever (클라이언트/UA)
- 송신자 → 메일 서버 , 송신자의 메일 서버 → 인터넷 = SMTP 프로토콜 - MTA 클라이언트 서버간 사용 / Simple Mail Transfer Protocol
- 수신자 메일 서버 → 수신자 클라이언트 (POP, IMAP 프로토콜) - MAA 클라이언트 서버간 사용
- Message transfer agent 서버 클라이언트간 소통에서 사용하는 프로토콜
- connection establishment : 클라이언트가 25번 포트로 TCP 연결을 만들고 난 후 SMTP 서버는 연결 단계 시작
- message transfer: SMTP 서버 클라이언트 모두 연결 설립 후 송수신 간 사이의 단일 메시지 교화
- connection termination : 메시지를 성공적으로 전송 후 클라이언트는 연결 종료
- message access agent 클라이언트 서버간 소통에서 사용하는 프로토콜
- 간단하지만 제한적인 기능
- POP3의 클라이언트는 수신측 컴퓨터에 설치 서버는 메일 서버가 설치된 소프트웨어에 설치
- POP3와 비슷한데 더 많은 기능 지원
- 다운로드 전에 메일 헤더 확인 가능
- 다운로드 전에 특정 문자열 내용 검색 가능
- 부분적 다운로드 가능
- 메일 서버에 메일 박스 이름 변경, 생성, 삭제 가능
- 메일 저장소에 메일 박스 계층 생성 가능
- non-ASCII 데이터를 보내기 위한 보조적 프로토콜
- 송신측의 non-ASCII 데이터를 NVT (Networkd Virtual Terminal) ASCII 데이터로 보내고 클라이언트 MTA로 보냄
- 수신측은 받은 데이터를 복원함
- HTML, MPEG, JPEG 등을 보냄
- 보안 없는 데이터 교환
- 서로 다른 시스템들은 메시지 표현 매커니즘이 다름 → 특정 원격 컴퓨터에 접근하기 위해 컴퓨터가 무엇이고 어떤 터미널 에뮬레이터를 사용하는지 알고 설치해야 함
- TELNET은 이 문제를 NVT (Network Virtual Terminal) 인터페이스를 정의해서 해결
- 보안 + 데이터 교환
- SSH Transoirt-Layer Protocol (SSH-TRANS)
- 메시지 교환의 비밀 보장
- 데이터 무결성 - 메시지 교환 중 방해자가 메시지 변형하지 못하게 보장
- 서버 인증 - 요청을 받는 서버가 요구하는 서버가 맞는지 보장
- 메시지 압축
- SSH Authentication protocol (SSH-AUTH)
- 서버 클라이언트 사이에 보안 채널 생성되고 서버가 클라이언트로부터 인증된 후, 서버를 위해 클라이언트를 인증하는 기능 제공
- SSH Connection Protocol (SSH-CONN)
- 인증을 통해 보안 채널 생성 후
- 클라이언트는 여러개의 논리적 채널 생성 가능
- 각 보안된 채널은 각각의 목적을 가짐 (파일 전송, 원격 로깅 등)
- 애플리케이션
- remote logging (puTTY, Tectia)
- file transfer (sftp, scp)
- port forwarding
- TCP/IP에서 IP 주소 - 인터넷 상 호스트 식별을 위해 사용
- 호스트의 IP 주소 - 이름 맵핑된 저장소
- 사용자가 호스트 이름으로 애플리케이션에 요청을 보내면 애플리케이션 클라이언트는 DNS 클라이언트에서 해당 이름을 보내면 IP 주소를 받환 받음 그 IP 주소로 네트워크 계층으로 접근
- 계층적 name space에서 트리의 각 노드들은 라벨을 가짐 최대 63 문자
- 루트는 null string
- DNS는 노드 자식들이 필요
- name servers의 계층
- 루트 서버 : 전체 트리의 루트, 어떠 정보도 저장하지 않지만 다른 서버들의 authority를 위임 받아서 서버 참조 가능, 전세계에 분산되어 있음
- 서버 타입
- primary : 존에 대한 파일을 저장하는 서버, 존 파일을 생성, 유지, 갱신하는 권힌
- secondary : 존에 대한 정보를 다른 서버로 전송하는 서버, 로컬 디스크 상의 파일을 저장, primary 서버로부터 모든 정보를 로드함
- name-address resolution : 이름 → 주소 맵핑
- resursive : 각 서버가 목적지 서버의 IP 주소를 찾기 위해 쿼리를 보내서 결과를 서버가 이전에 뭐리를 보냄 체인을 통해 보냄
- iterative
- caching
- resource records
- domain name : 자원 레코드 식별
- value : 도메인 이름 정보
- TTL : 정보가 유효한지 나타내는 숫자
- class
- type : value가 해석되는 방식
- DNS client - resolver
- 주소-이름 매핑 찾아주는데 사용
- nslookup
- UDP, TCP 모두 사용 가능 (응답 메시지가 512 바이트보다 작은 경우 사용) 포트 53
- centralized
- 디렉터리 시스템 : 피어 리스트, 각 피어가 제공하는 것 리스트 (클라이언트 서버 패러다임)
- 파일 저장 및 다운로드만 P2P
- decentralized
- 중첩 네트워크
- 비구조적 네트워크
- 노드들인 랜덤으로 연결
- 검색 비효율적
- 엄청난 트래픽 필요 Gnutella, Freenet
- 구조적 네트워크
- 노드 연결 규칙 정의
- 쿼리 해결 쉽게 가능
- DHT (distributed hash table) → BitTorrent 사용 예
- 2^m (m은 주로 160) 사이즈의 주소 공간 사용
- 주소 범위 0 ~ 2^m-1
- 노드 식별자 = hash(peer ip 주소)
- 객체 (파일,,) 식별자 : m bit 정수 (key) = hash(객체이름)
- Chord, Pastry, Kademlia
- 노드와 객체 식별자 = 2^m
- 시계 방향 원형에 분산되어 있는 노드와 객체
- 데이터 객체 k, 노드 N
- 주소 = mod 2^m
- k보다 큰 N중 가장 가까운 N = successor of k , value(k,v) → v = 객체를 가진 피러 서버에 대한 정보
- 노드가 쿼리 풀기
- 주어진 k
- 다른 노드로 포워딩하거나 해당 k를 가지고 있는 노드 식별자를 찾아야 함
- 핑거 테이블 (각 노드마다 가지고 있는 라우팅 테이블)
- 각 노드의 핑거 테이블들은 m successor을 엔트리로 갖고 각 노드는 오직 하나의 predecessor만을 갖는다.
- N=5의 핑거 테이블
- target key = 5+1, 5+2, 5+4, 5+8, .... ⇒ 각 successor는 k보다 크면서 가장 가까운
- 라우팅 하는 방식은 N5 0101, k8= 1000→ 공통부분이 0 이므로 N테이블의 0 에 따라 N10 테이블로 가서 이거 반복
- 식별자 x, y ⇒ distance(x,y) = x XOR y
- 노드, 객체 식별자 = m-bit 식별자
- 이진 트리의 단말 노드에 분산된 2^m 주소 공간으로 생성
- k n은 존재하는 노드N중 거리를 XOR로 계산해서 그 값이 가장 N에 저장됨
- ex) m=4 ⇒ 식별자 공간 16
- k3 → 3 XOR 3 = 0 → N3에 저장
- k7 → 6 XOR 7 = 1 < 6 XOR 8 = 14 → N6에 저장
- 각 노드는 m 서브트리를 갖고, m 열, 1행 을 가진 라우팅 테이블이 있음
- 서브트리 i는 common prefix length 를 나타냄
- 각 열은 common prifiex length 가 같은 노드 식별자를 가지고 있음
- ex) m = 4⇒ 4행 라우팅 테이블
- row = 0 ⇒ 공통앞부분이 0 → N6, N15
- 15 주변에 있는 노드 N11, N8, N6중 가장 가까운 곳을 찾으면 6
- ex) N0이 k12 찾아야 함
- N0와 k12의 공통 프리픽스길이 = 0
- N0은 라우팅 테이블에서 0번 열의 노드 N8에 메시지 전달
- N8과 k12의 공통프리픽스 길이 = 1
- N8은 1번 행에 있는 노드에 메시지 전달 N15
- N15가 k12 가지고 잇음
- 클라이언트 서버 패러다임에서 소통은 두 소켓 간 소통이므로 소켓 두개의 소켓 주소 필요
'컴퓨터 공학 > 컴퓨터 네트워크' 카테고리의 다른 글
[Python3/컴퓨터 네트워크] 소켓 프로그래밍 : 멀티 쓰레드 (0) | 2021.05.03 |
---|---|
[컴퓨터 네트워크] Transport Layer 전송 계층 기본 개념 정리 (0) | 2021.05.02 |
[컴퓨터 네트워크] 컴퓨터 네트워크 Introduction 정리 (0) | 2021.05.02 |
[컴퓨터 네트워크] Chapter4) Network Layer 네트워크 계층 (0) | 2021.04.20 |
[Python3/컴퓨터 네트워크] 소켓 프로그래밍 : html request를 보내는 클라이언트와 request 받은 파일을 찾아 웹 브라우저로 보여주는 서버 프로그램 (0) | 2021.04.08 |