🍏 HTTP 1.1
✅ Web Client and Servers
- 언어별로 http를 지원할 수도 있고 아닐수도
- 웹브라우저 채우기 보다 서버와 서버의 정보교환에 집중
- 주고받는 데이터의 형태에 맞추서ㅓ 주고받음
tcp udp zeromq도 프로그램간 정보교환 - RESTful : 정보 교환하는 방법
http = request(client to server) + response (server to client) = simple !
http는 사람들이 디버깅하기 쉽게 도ㅔㅣ어있음
✅ Resources
Resource : 글자, 파일 , 이미지
- Static content : request가 오기 이전에 이미 만들어져있기 때문에 request 이후 바뀌지 않는다. 하드디스크에서 빼오는 것
ex) file system에 저장되어있는 Video Clip 기타 등등- Dynamic content : request를 할 때 정보를 만들어냄 / logic server 필요
Server : 요청을 받아서 static와 dynamic을 구분해서 넘긴다.
✅ Resources - MIME
- email 첨부파일로 부터 시작
ex) email
웹서비스가 도입되기 10년 전부터 일반화
이메일의 기능 확장(있던거 활용) -> 다양한 첨부 기능 추가
✅ Resources - URI
- URI = Uniform Resource Identifier ( URL / URN )
- URL : resource(정적 or 동적)의 위치를 설명
주소창 : URL을 타이핑 하는 곳- R = resource
- L = locater : 위치
✅ Transactions
- GET : 내놔
- HTTP/1.0 : 이 버전에 맞춰
왜 request 할때 목적 주소를 넣어놓을까? 어차피 IP가 제공할텐데 -> 중간에 http를 끊어서 서버랑 client를 연결하는 서버가 있어서 = 프록시 서버 나중에 설명~
- http2,3은 google이 개발
🍏 HTTP Methods
- GET
- PUT
- DELETE
- POST
- HEAD
✅ Status Codes
- 200 : OK ~
- 302 : Redirect / 나한테 없으니 쟤한테 가
- 404 : Not Found / 니가 요청한 file 없다 (server는 제대로 동작중)
redirect server : ex) 코레일 추석 사이트
✅ Messages
- Request : 명령 + 리소스 URL + 프로토콜 버전
- Response : 응답 + 컨텐츠
- http 1 = 인간이 읽고 쓰기 편하게
- http 2,3 = 컴퓨터가 보기 편하게
웹서버 웹브라우저도 캐시를 가짐. 한번 다운 받은거 또 받고싶지 않아..
✅ Transport layer under HTTP
- HTTP 밑에 TCP/IP를 쓴다 -> simple
- HTTP는 연결 설정 및 해제 과정 x - TCP를 믿는다
- 따라서 에러검출이나 메세지 순서에 신경쓰지 않겠다고 한것.
https : security 버전 / server와 client 사이에 어떤 누구도 접근할 수 없음. 암호화 하는것(TLS,SSL에서) / 대신 성능 저하 / 최초 연결 시 암호화하는 부분이 있어서 이때 느려진다
✅ Proxy
= HTTP 기반 서버
- CLIENT / SERVER 모두가 볼 수 없음
- Network의 나가거나 들어오는 입구에 위치해서 항상 경유하도록 한다.
- Performance Optimization = client가 server에게 요구했는데, 자주 접속하던 애면 contents를 proxy가 미리 가지고 있어서 client가 접속했을 때 server까지 안가고 proxy가 제공한다.
- 보안 / 서비스 관리 팀에서 큰 역할을 한다.
✅ Methods - GET
- File이나 Resource를 가져오는 것
✅ Methods - PUT
- File을 원하는 곳에 저장해줘~
✅ Methods - HEAD
- file을 빈번히 가져오는 경우, file이 바뀌지 않으면 굳이 안가져와도 됨. file에 대한 정보만 알고싶을 때 GET 대신 HEAD 사용
- file을 통채로 보내지말고 head만 내놔
- 본체는 없고 정보만
✅ Methods - POST
- GET/PUT : file 단위
- POST : 함수의 입력 파라메터 전달
- 컴퓨터들 사이 정보 전달을 위해서도 HTTP를 쓴다~ 특히 server에서 많이 씀
✅ Methods - TRACE
client sever 사이에 proxy가 있다
trace = proxy를 확인하기 위해사용 / 아.. 서버로 보내려면 proxy를 거쳐야하구나
- 회사 내에서 컴퓨터들 끼리 전달할 때 디버깅용
✅ Methods - OPTIONS
- 이 서버가 제공하는 기능들을 알려줘~
- Response : 나는 Allow에 이런이런 것들을 지원해
✅ Status Codes
- Redirect
여기 없으니까 다른 곳으로 가! 새로운 곳의 location을 준다.
앞서에서 Head message가 있었죠
-> 응답으로 resource에 대한 정보만 제공
- If Modeife-- : 이 시간 이후에 수정이 됐으면 나한테 보내줭 -> response에 파일이 없음
= 캐시를 아낄수있다? 다시
1.1 목적 1) .,,/2)보안
✅ HTTP Client Modules in Python
http.server를 임포트하면 세개 클래스 쓸 수 잇고
python -m http.server 실행하면 이 directory를 root로 잡고 server를 띄움
requesthandler :
✅ HTTP sample code 목적
- 웹 서버 & 브라우저 목적이 아닌 "정보교환"
contents 전송을 목적으로 만들어진 것이 아님.
file 업로드,전송 기능이 없는 것은 의도된것
🍏 HTTP는 어떻게 영상을 스트리밍?
- HLS
파일을 속도별로 나눠서 저장하기도 하는데, 하나의 속도에서도 몇 초 단위로 잘게 쪼개짐.
= 영상 스트리밍 표준기법
720 get reqeust-response 계속 하다가, 오 출력이 잘 되는데~ 하면 1080 쪽으로 바꾼다. 브라우저가 느리거나 잘 안되면 다시 화질 다운.
- [ 라이브 스트리밍 ] -> 상식으로 이해를 해봐랑~
젤 만만한 720을 고른다. 화면을 몇초 단위로 쪼개서 압축한 파일이 필요. 카메라에서 한장한장 날라오는게 아니라 몇초동안 압축된 파일이 날라오는 것. 지연이 발생함. 실시간이라고 하지만 지연이 발생하고, 정해진 시간마다 보내지는 것.
p.43
- ㅇ
vp 확장자 - 구글이 영상 압축기술,이미지 압축기술을 자체적으로 만든것. 자체 기술을 이용하니 m pack(mp3 mp4 ..)에 돈을 안내도 됨. - Carbon
구글이 만든 언어 / C언어를 끌어안을 수 잇음
-> 이렇게 구글은 다양한 시도를 함 /
[16] Monolithic, SOA, Microservices 방식에서 프로그램을 구현하는 것이 어떻게 차이가 있는지 설명합니다.
[17] Monolithic, SOA, Microservices 방식에서 팀의 구성, 개발 언어 및 DB의 선택이 어떻게 차이가 있는지 설명합니다.
🍏 Monolithic vs SOA vs Microservice
= 네트워크 프로그래밍의 변천사
- Monolithic = 비싼 컴퓨터 -> TCP
- 거대한 하나의 프로그램
- 언어, DB등등을 하나도 통일해야함
- SOA
= Service Oriented Architecture- 여러개로 쪼갠 후 네트워크 처리.
- 컴퓨터 별로 기능이 상이
- 각자 언어, DB 통일할 필요없음. CPU들이 협업
- Microservices
점점 더많이 쪼개짐. 컴퓨터 개수가 많아지고 쪼개진 애들끼리 통신 해야하니까 자연스럽게, 웹서버에 붙어서 논문 자료를 가져와야할 http가 옆에있는 컴퓨터끼리 대화를 하는 server-to-server로 바뀌게 되는 거죠. 과거의 통신기술(멀리있는애들끼리 통신) : SKT / 현재 통신 기술(마이크로화 되어있는 서비스들끼리의 통신) : 구글이나 페이스북이 주도.- 테스트-출시 까지의 과정이 짧아짐
- continuous integrity
- 네트워킹이 서버쪽으로 많이 들어가기 시작했고 HTTP 같이 이해하고 사용하기 쉬운 기술이 나오면서 SOA 쪽으로 바뀌기 시작함.
- 어차피 네트워킹 있으니까, 연결할 수 있으니까 서버들을 쪼개서 기능을 나눠준다. 기능별로 분할된다. 그들 간에는 HTTP / ZMQ / TCP UDP 등으로 정보를 전달.
- 처음에는 분할된 애들도 꽤 무거웠는데 점점 더 잘게 쪼개게 됨 -> Microservice
- 2010 : openstack
micro화 된 서비스들을 굉장히 많은 컴퓨터들에 뿌림.
virtual machine은 OS 돌릴 때 하나의 cpu가 필요함. 4개의 cpu -> 3개의 프로그램
- Docker
더이상 guest os가 필요 x . 원래 linux는 다중사용자를 위한 것. container 기술(초록색 박스) . 필요없으면 뽑고 버리기 -> 느려지지 않음
🍏 SOAP & REST / RESTful
- TCP때랑 차이점
RESTful : 호출하는 함수이름과 data를 js 형식으로 보낸다.
✅ JSON Data Format
- json은 javascript python처럼 데이터(정수,실수,배열...)를 표현하는 방식
- 웹 브라우저는 JS 번역기를 내장하기에 웹 서비스에 유리
- js에서 데이터를 사용하는 문법만 사용할 것.
대부분 컴퓨터가 js를 이해할 수 있음. - example)
- key-value 형태 - 파이썬의 dictionary
중괄호 사용 - members -> list
- key-value 형태 - 파이썬의 dictionary
✅ JSON Standard Library in Python
-
python은 json을 다룰 수 있는 표준 library가 있다.
방금처럼 서버나 다른프로그램으로부터 받은 정보가 json이면 저런 함수들 이용 -
JSON 대표함수
- Python <-> JSON 형태 변화 규칙
요런식으로 http1.1을 통해 정보를 주고받았으니 pyton의 정보를 그대로 보내는 거예요~
json format을 이용해 전달햇기때문에 다른 언어를 이용해도 같은 방식으로 변환해서 문제 XX
✅ REST & RESTful
'http1.1로 json file으로 실어나른다'보다 세련된게 없을까. 생산성을 높이고 개발 용이성이 좋도록
- REST
- SW Architectural Style
- REST : http를 기반으로 상대방의 기능을 호출하거나 하는 철학
- 기존의 json방식을 좀 더 세련되게
- RESTful
- 설계 철학인 REST를 만족시켜서 프로그램에 집어넣는 것
- Any Web Site
✅ REST 구조에 대한 제한 조건
http1.1은 온갖 메소드를 사용하는데 REST는 형태를 갖춘 일정의 권장사항을 줘서 http 1.1을 좀 더 제약되게 사용할 것
- 인터페이스의 일관성
- 무상태 : client의 request는 독립적으로 동작
- 계층화 : proxy를 포함한 수많은 server로 구성되어 있다. 수많은 애들한테 작업을 분리
- URL에 원하는 기능과 데이터를 넣는다.
- 원래 리소스에 해당하는 디렉토리(file찾기)가 들어갔다면 지금부터는 함수의 이름과 데이터를 실어나르도록 하겠다.
- 문자열을 만들어서 원하는 기능을 호출하고 값도 쓸 수 있다.
- GET : Read - client가 요구한 값, 데이터를 읽어서 return함
- PUT : Create - 이 값을 너에게 줄테니 DB에 저장해라.
✅ REST API Design
- CRUD 원칙
http의 method를 매핑해준다
- Create - POST
- Read - GET
- Update - PUT
- Delete - DELETE
- 네개의 command와 http를 통해 어떤식으로 복잡한 서버간에 통신을 할 지는 회사의 몫
- RESTful api
저 네개의 command를 통해 정보를 주고받는 것
✅ Flask & Flask-RESTX
python은 standarad 보다는 잘 되어있는 framework를 사용하길 권장
