[Computer Network] Application Layer2

Y_Y·2022년 10월 21일
0

Computer-Network

목록 보기
4/6

사용자와 서버의 상호작용 : 쿠키

  • HTTP 서버는 상태유지 하지 않음
    • 수천개의 연결을 다룰 수 있는 고성능 웹 서버 개발 가능
    • 문제점 : 사용자 접속 제한, 사용자에 따른 컨텐츠 제공 불가능

쿠키

  • 상용 웹사이트는 쿠키사용
    • 1) HTTP 응답 메시지 쿠키헤더 라인
    • 2) HTTP 요청 메시지 쿠키헤더 라인
    • 3) 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키파일
    • 웹사이트 백엔드 데이터베이스

  • client에 유저의 상태를 저장
  • Server에는 백엔드 DB가 쿠키로 저장

웹 캐싱

  • 서버와 단말에 모두 존재

    • 서버측 캐싱, 단말측 캐싱
  • 캐싱은 HTTP header에 If-modified-since를 사용하여 체크 함

  • 전형적으로 ISP에 의해 설치됨 (브라우저를 미리 설정)

  • 웹 캐싱 사용이유?

    • Client 요청에 대한 응답시간을 줄일 수 있다.
    • 기업체의 외부 엑세스 링크에 대한 트래픽을 줄임
    • 영세한 컨텐츠 사업자에게도 효과적으로 컨텐츠를 제공하게 함
  • Client 캐싱 검색 내용이나 웹 사이트 이미지 등등 정보를 로컬에 저장

  • 서버측 캐싱 프록시 서버가 서버 기능을 수행함

웹 캐싱(서버측 캐싱)

  • Goal : 기점 웹 서버의 관여 없이 Client의 요청을 만족시킴

  • 사용자 브라우저 설정 : 프락시 서버를 통한 엑세스로 설정

  • 브라우저는 모든 http 요청을 프락시 서버로 요청

    • 캐싱된 객체 : 프락시 서버가 캐싱된 객체 리턴
    • 캐싱된 객체가 없는 경우 프락시 서버가 기점서버에 요청한 후 결과를 Client에 전송

웹 캐싱 예 (웹 캐싱을 사용할 경우)

  • 적중률이 0.4인 경우

  • 트래픽 강도 =

전자메일: STMP [RFC 2821]

  • Client to Server를 신뢰성 있는 이메일 전송을 위해 TCP 포트25 사용
  • 직접전송 : 송신서버에서 수신서버로 전송
  • 전송 3단계 :
    - Handshaking (greeting)
    - Transfer of messages
    - Closure
  • Command/response interaction :
    - Commands : ASCII text
    - Response : status code and phrase
  • 메세지는 7-bit ASCII 코드만 지원
터미널 명령어
C : telnet address@email.com 25
S : 220
C : mail from : example@email.com
S : 250 Ok
C : rcpt to : example@email.com
S : 250 Ok
C : data
S : 354 go ahead
C : subject: Test E-Mail
This is example email
.
S : 250 Ok

SMTP

  • SMTP는 지속연결을 사용
  • SMTP는 7비트 ASCII로 된 메세지(헤더와 바디)를 요구함 (인코딩 필요)
  • SMTP 는 메시지 종료를 위해 CRLF.CRLF를 사용

HTTP와의 차이점:

  1. HTTP : pull vs SMTP : push
  2. SMTP는 각 몸체를 포함하여 각 메시지가 7비트 ASCII포맷 HTTP 는 제한이 없다.
  3. 텍스트와 이미지로 구성된 문서를 다루는 방법 SMTP : 모든 메시지의 객체를 한 메시지로 만듬 HTTP : 응답메시지에 각 객체를 캡슐화

  • base 64 -> 6bit씩 4개 transfer

DNS : 디렉토리 서비스

DNS services

  • 호스트 네임을 IP주소로 변경
    - canonical, alias names
  • 메일 서버 엘리어싱
  • 부하분산
    - 중복 웹 서버 : 여러 개의 IP 주소가 하나의 이름으로 맵핑
  • UDP 53번 포트 사용

DNS structure

  • 루트 DNS 서버
    - 400개의 서버를 13개의 기관이 관리
  • 최상위 레벨(TLD : Top-Level Domain) 서버
    - .com .edu .kr .jp 등
  • 책임 DNS 서버
    - 기관에서 관리하는 서버
C : nslookup www.naver.com
S : www.naver.com canonical name = www.naver.com.nheos.com
Name : www.naver.com.nheos.com

DNS records

DNS : distributed database storing resource records (RR)

RR fortmat : (name, value, type, ttl)

DNS protocol, messages

  • Query and reply messages, both with same message format

비디오 스트리밍과 CDN

CDN : Content Delivery Network

컨텐츠를 제공하기 위해 가장 가까운 인프라를 가지고 있는 회사 (호스트)

CDNs : Content Distribution Networks
ex) Netflix stores copies of Madmen

  • CDN : 각 CDN 노드에 컨텐츠 저장
  • 가입자는 CDN으로부터 컨텐츠 요청
    - 근접 노드로 컨텐츠 재생 요청
    - 노드가 혼잡한 경우 다른 버전(혹은 저속)의 컨텐츠를 선택

Client의 IP를 확인하여 가장 근거리에 있는 회사로부터 manifest file 제공

-> manifest file에 영상의 화질에 대한 정보 등등 저장되어 있음.

DASH : Dynamic Adaptive Streaming over HTTP
-> HTTP를 이용해서 DAS를 한다.

User는 시간대비로 상황이 좋으면 고품질, 나쁘면 저품질로 시청

Socket programming

  • Goal : 소켓을 이용하여 클라이언트/서버응용 프로그램을 작성함

UDP :
TCP :

UDP를 이용한 소켓 프로그래밍

  • 핸드셰이크 과정이 없다
  • 송신호스트는 송신하는 각 바이트 묶음에 IP주소와 포트번호를 붙여서 패킷 생성
  • 서버호스트는 수신된 패킷으로부터 IP address와 포트 추출

-> UDP는 전송된 데이터가 손실될 수 있다.

Client/server socket interaction : UDP

AF_INET = Address Familly_INET

Ex) Python UDP Client/Server

! encode() : String to Binary
serverName : IP address or server name

message = Binary
! decode() : Binary to String

TCP를 이용한 소켓 프로그래밍

Client/Server socket interaction : TCP

  • 서버 준비
    - 서버 프로세스가 먼저 실행
    - 서버는 클라이언트로 부터 초기접속을 처리하는 소켓을 가져야 함 (서버 소켓)

  • 클라이언트 프로세스는 서버에게 TCP연결 시작
    - 클라이언트는 소켓 객체를 생성
    - 소켓객체를 생성시 서버의 IP주소와 프로세스의 포트번호를 명시
    - 클라리언트가 소켓을 생성시 클라이언트 TCP는 서버 TCP와 3방향 핸드셰이크로 연결을 설정함
    - 서버는 클라이언트가 연결을 요청하면 서버는 클라이언트와 통신을 위한 새로운 소켓을 생성함 (연결 소켓)

연결 소켓은 Vec(송신 IP주소,송신 포트넘버, 수신 IP주소 수신 포트넘버)로 구성
UDP는 한 개, TCP는 연결 숫자만큼 소켓 생성
-> TCP는 연결 소켓에 따라서 소켓 생성

Ex) Python TCP Client/Server

Cient Connect : 서버로 접속 요청
clientSocket.recv(1024) -> 1024 byte.

Web server

1️⃣ Reference

profile
남을 위해(나를 위해) 글을 쓰는 Velog

0개의 댓글