HTTP 메서드(GET, POST) GET : 리소스 조회 POST : 요청 데이터 처리, 주로 등록에 사용 PUT : 리소스를 대체, 해당 리소스가 없으면 생성 PATCH : 리소스 부분 변경 DELETE : 리소스 삭제 기타 메서드 HEAD : GET과 동일하지만 메시지 부분을 제외하고 상태 줄과 헤더만 반환 OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용) CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정(거의 안씀) TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행(거의 안씀) GET 리소스 조회 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달 메시지 바디를 사용해서 데이터를..
HTTP API를 만들어보자 요구사항 : 회원 정보 관리 API를 만들어라. 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 API URI 설계 URI(Uniform Resource Identifier) 회원 목록 조회 /read-member-list 회원 조회 /read-member-by-id 회원 등록 /create-member 회원 수정 /update-member 회원 삭제 /delete-member URI에서 가장 중요한 것은 "리소스 식별" API URI 고민 리소스의 의미는 뭘까? 회원을 등록하고 수정을 조회하는게 리소스가 아니다! 예) 미네랄을 캐라 -> 미네랄이 리소스 회원이라는 개념 자체가 리소스다. 리소스를 어떻게 식별하는게 좋을까? 회원을 등록하고 수정하고 조회하는 것을 모..
모든 것이 HTTP - 한번 더! 모든 데이터들을 HTTP로 보낸다. 바야흐로 HTTP의 시대 http 버전 ~ 요청한거 200 OK야 공백라인 오고 필요한 http 응답 메세지가 들어온다 참고) HTTP 요청 메세지도 html을 가질 수도 있다. 요청 메시지 시작 라인 (요청 메시지) start-line = request-line / status-line request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터) HTTP 메서드 (GET : 조회) 요청 대상 (/search?q=hello&hl=ko) HTTP Version 종류 : GET, POST, PUT, DELETE 서버가 수행해야할 동작 지정 GET : 리소스 조회 POST : 요..
클라이언트 서버 구조 Request Response 구조 클라이언트는 서버에 요청을 보내고, 응답을 대기 서버가 요청에 대한 결과를 만들어서 응답 클라이언트와 서버를 개념적으로 분리를 하고, 비즈니스 로직, 데이터는 전부 서버에 몰아넣는다. 그리고 클라이언트는 UI와 사용성에 집중한다. 그러면 클라이언트와 서버가 독립적으로 진화할 수 있다. UI를 어떻게 그릴지, 클라이언트가 PC, 휴대폰, TV, 아이폰, 안드로이드는 UI/UX를 담당하면 된다. 클라이언트는 딱 거기에만 집중을 하면되고, 비즈니스가 잘돼서 트래픽이 100배 폭주했다면, 클라이언트를 손댈 필요가 없다. HTTP는 클라이언트, 서버 구조인데, 기본적으로 클라이언트가 리퀘스트를 보내면 서버가 응답할 때까지 기다렸다가 응답하면 그거에 따라 움..
HTTP(HyperText Transfer Protocol) 문서 간의 링크를 통해서 연결할 수 있는 프로토콜 지금은 HTTP 메시지에 모든 것을 전송 HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) 거의 모든 형태의 데이터 전송 가능 서버 간의 데이터를 주고 받을 때도 대부분 HTTP 사용 지금은 HTTP 시대! HTTP 역사 HTTP/0.9 1991년 : GET 메서드만 지원, HTTP 헤더 X HTTP/1.0 1996년 : 메서드, 헤더 추가 HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전(대부분 기능이 다 들어있음) RFC2068 (1997) -> RFC2616(1999) -> RFC7230~7235(2014) HTTP/2 2015년 : ..
웹 브라우저 요청 흐름 https://www.google.com/search?q=hello&hl=ko DNS 서버 조회(200.200.200.2) HTTPS PORT 생략, 443 HTTP 요청 메세지 생성 소켓 라이브러리를 통해 OS 통해 TCP/IP 계층에 전달을 해야함 SYN, SYN+ACK, ACK 해서 구글 서버와 연결 TCP/IP에다가 패킷을 한번 씌운다. 그럼 이걸 인터넷망으로 던지고, 수많은 노드를 통해가서 구글 서버가 요청 패킷이 도착하면 tcp/ip 패킷을 다 까서 버린다음에 http 메시지를 해석함 구글 서버에서 HTTP 응답 메세지를 만든다. 구글도 응답 패킷을 만들고, tcp/ip 패킷을 또 보낸다. 응답 패킷이 도착하면 웹브라우저에서 이를 HTML 렌더링한다.
URI 웹 브라우저 요청 흐름 URI(Uniform Resource Identifier) 리소스를 식별하는 통합된 방법 URI UR는 로케이터(Locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다. URL : Resource Locator 우상욱이 현재 어디 살고 있다. URN : Resource Name 우상욱 그 자체 중간에 어딘가 이름을 집어넣으면 나오는게 거의 url만 씁니다. URI 단어뜻 Uniform : 리소스 식별하는 통일된 방식 Resource : 자원, URI로 식별할 수 있는 모든 것(제한 없음) Identifier : 다른 항목과 구분하는데 필요한 정보 URL, URN 단어 뜻 URL - Locator : 리소스가 있는 위치를 지정 URN - Name : 리소스에 이..
DNS IP는 기억하기 어렵다. 그리고 문제는 IP는 변경이 될 수도 있다. 그래서 도메인 네임 시스템(Domain Name System)이 생겼다. DNS 서버에 도메인을 등록할 수 있다. DNS 서버에 google.com의 IP를 주세요라고 요청하면, IP를 준다. 그래서 google.com에서 IP가 바뀌면 DNS 서버에 이걸 바꿔놓으면, 전화번호부 처럼 사용할 수 있다. 정리 인터넷 통신 IP(Internet Protocol) TCP, UDP PORT DNS
PORT : 포트는 배가 도착하는 항구 IP는 서버를 찾는 것 PORT는 애플리케이션을 찾는 것 웹브라우저가 HTML을 만들어서, 100.100.100의 포트 10010번으로 보낸다. 서버에서 어떻게 포트를 알 수 있나? tcp/ip 패킷 만들 때 다 써서 보내니까, 반대로 써서 보내면 되니까 IP는 아파트고, 포트는 몇 동 몇 아파트를 하나의 서버나 PC로 보면 된다.
인터넷 프로토콜 스택의 4계층 IP의 단점을 TCP를 살짝 올려서 그걸 보완해주는 역할을 한다고 보면 된다. UDP는 비연결성, 비신뢰성, 순서을 보장해주진 않지만 장점이 있다. 프로토콜 계층 소켓 라이브러리라는 걸 보통 쓰는데, 소켓 라이브러리를 통해서 os 계층에다가 hello라는 메세지를 넘긴다. tcp에서 tcp 정보를 씌우고(녹색 씌우는 느낌) 그 밑에 ip와 관련된 데이터들을 씌웁니다. 이렇게 IP 패킷을 생성하고, 그 안에 IP 정보, TCP 정보, 메시지가 포함 되어있다. 그게 이더넷 프레임을 통해서 나간다. 패킷 : 진짜 패키지(수화물 + 덩어리(버킷)) -> 택배 박스에 데이터 넣듯이 해서 보내는 거랑 비슷 TCP 특징(신뢰할 수 있는 프로토콜) IP만으로 해결이 안됐던 전송 정보를 넣..
인터넷 네트워크 인터넷 통신 인터넷에서 컴퓨터 둘은 어떻게 통신할까? 내가 한국에 사는데 미국에 있는 친구한테 메시지를 보내야한다. 인터넷 망을 통해서 메시지를 보내야한다. IP(인터넷 프로토콜) 복잡한 인터넷망에서 미국에 있는 친구한테 보내려면 최소한의 규칙 필요 이는 IP 주소를 통해 가능하다. 클라이언트인 내가 IP 주소를 부여받아야한다. 지정한 IP 주소(IP Address)에 데이터 전달 패킷(Packet)이라는 통신 단위로 전달 IP 패킷 정보 그럼 친구가 메세지를 받았으면, 똑같이 한다. 출발지 IP를 넣고 목적지 IP를 넣고 던진다. 노드별로 주소 물어가면서 던지면서 최종적으로 클라이언트에게 다시 OK 메세지를 전달해준다. IP 프로토콜의 한계 비연결성 패킷을 받을 대상이 없거나 서비스 불..
HTTP를 배워야하는 이유 HTTP를 웹 기술과 관련된 개발을 오랫동안 하더라도 HTTP에 대해 고민을 많이하게 된다. HTTP 상태 코드는 어떻게 하고 싶을까? 잘못된 자료도 많고, HTTP 스펙을 보자니 실무에 도움이 될까 고민이 있다. 개발자는 평생 HTTP 기반 위에서 개발해야한다. 실무에 꼭 필요한 HTTP 지식 모바일 앱 웹 프론트엔드 백엔드 백엔드 개발자 분들에게 도움이 가장 많이 될 것
