사용자와 서버의 상호작용 : 쿠키
- 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와의 차이점:
- HTTP : pull vs SMTP : push
- SMTP는 각 몸체를 포함하여 각 메시지가 7비트 ASCII포맷 HTTP 는 제한이 없다.
- 텍스트와 이미지로 구성된 문서를 다루는 방법 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.comDNS 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
