일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 바깥쪽 여백
- 콘텐츠 영역
- 클라이언트와 서버 구조
- 경계선
- URL
- 카우치코딩
- connectionless
- 응답 헤더
- HTTP
- 팀프로젝트
- HTTP 메시지 바디
- IP
- margin
- Content
- couchcoding
- 무상태
- CSS
- 박스모델
- 프로토콜
- 서버
- 협업프로젝트
- 안쪽 여백
- HTTP 메시지
- 선택자
- 클라이언트
- padding
- border
- HTML
- 요청 헤더
- 6주포트폴리오
- Today
- Total
목록HTTP (13)
정리하고 기록하며 성장하는
HTTP 메서드 클라이언트가 서버에게 요청할 때 기대하는 행동 GET : 데이터를 달라 POST : 데이터를 줄테니까 처리를 해달라 HTTP 메서드 목적 자원(리소스)에 대해 서버가 수행해야 할 동작을 지정하기 위해 사용 HTTP 메서드 종류 GET : 리소스 조회 POST : 요청 데이터 처리 , 주로 등록에 사용 데이터를 담아서 서버에게 보내는 경우 데이터를 주면 서버가 처리해 준다 PUT : 리소스를 대체 , 해당 리소스가 없으면 새롭게 생성 PATCH : 리소스 부분 변경 예) 회원의 이름 변경 DELETE : 리소스 삭제 기타 메서드 HEAD : GET과 동일하지만 메시지 부분을 제외하고 상태 줄과 헤더 부분만 반환 OPTIONS : 브라우저가 서버에게 지우너하는 옵션들을 미리 요청하고 허가된 ..
요구사항 회원 정보 관리 API 만들기 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 API URL 설계 URL (Uniform Resource Identifier) 회원 목록 조회 - /read-member-list 회원 조회 - /read-member-by-id 회원 등록 - /create-member 회원 수정 - /update-member 회원 삭제 - /delete-member 이렇게 설계 하는 것이 좋은 URI 설계 일까? 리소스를 식별하는 것이 좋은 URI 설계 이다 리소스 - 개념 자체를 의미한다 예) 미네랄을 캐라 -> 미네랄이 리소스이다 회원을 조회 하라 -> 회원이 리소스이다 리소스를 어떻게 식별하는것이 좋을까? 회원을 등록 , 수정 , 조회 하는 행위에 해당하는 것을 모..
HTTP 메시지 구조 start-line 시작 라인 header 헤더 empty line 공백 라인 (CRLF) message body HTTP 요청 메시지 http 요청 메시지도 본문에 필요한 body 부분을 가질수 있다 GET /search?q=hollo&hl=ko HTTP/1.1 HOST:www.google.com 요청 메시지 - HTTP 메서드 start-line = request-line(요청) 과 status-line(응답)이 있다 request-line method SP(공백) request-target SP (요청하는 대상) HTTP-version CRLF(엔터) 종류 : GET , POST , PUT , DELETE 서버가 수행해야 할 동작 지정 GET : 리소스 조회 POST : 요청 ..
TCP/IP 프로토콜 연결을 유지하는 모델이다 클라이언트1 과 서버의 요청 응답이 끝나고 다른 클라이언트가 서버에게 요청을 보내더라도 클라이언트1과 서버의 연결은 끊어지지 않은 상태이다 연결을 유지하지 않는 모델 (비연결성) 자원을 서버와 클라이언트가 요청과 응답을 받을 동안에만 유지를 하고 아닐때는 끊어버린다 최소한의 자원으로 서버를 유지할 수 있게 된다 즉 , 클라이언트1과 서버의 요청과 응답이 끊어지면 TCT/IP 프로토콜의 연결이 종료된다 HTTP 기본적으로 연결을 유지하지 않는 모델이다 일반적으로 초 단위 이하의 빠른 속도로 응답을 보낸다 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 적다 비연결성을 사용했을 떄 장점 서버 자원을 매우 효율적으로..
무상태 프로토콜 스테이스리스 (Stateless) 서버가 클라이언트의 상태를 보존하지 않는다 클라이언트가 요청할 때부터 필요한 데이터를 그떄그떄 담아서 넘겨준다 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다 응답 서버를 쉽게 바꿀수 있다 (무한한 서버 증설 가능) 서버는 상태를 보관하지 않는다 스케일 아웃 - 수평 확장에 유리하다 한계 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다 더보기 무상태 - 로그인이 필요 없는 단순한 서비스 소개 화면 상태 유지 - 로그인 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지시켜야 한다 일반적으로 브라우저 쿠키와 서버 세션등을 사용하여 상태를 유지 시킨다 상태유지는 최소한만 사용한다 꼭 필요한 경우에만 어쩔수 없이 사용해야..
클라이언트와 서버 구조 Request Response 구조 클라이언트는 서버에 요청을 보내고 응답을 대기한다 서버가 요청에 대한 결과를 만들어서 응답해준다 클라이언트와 서버를 분리했을 때 장점 비즈니스로직과 데이터는 서버가 담당한다 클라이언트는 UI 와 사용성에 집중한다 클라이언트와 서버가 각각 독립적으로 진화할 수 있다 클라이언트가 요청을 보내면 서버가 기다렸다가 응답을 받은 후 요청에 대한 결과를 만들어서 응답해 준다
HTTP (HyperText Transfer Protocol) html을 전송하는 프로토콜 모든 것은 HTTP 프로토콜에 담아서 전송한다 이미지 , 음성, 영상 , 파일 , JSON, XML (API) 거의 모든 형태의 데이터가 전송 가능하다 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다 HTTP/1.1 가장 중요한 버전 기반 프로토콜 HTTP/1.1 , HTTP/2는 TCP 프로토콜 위에서 동작한다 HTTP/3는 UDP 기반으로 개발되어 있다 성능 최적화가 되어 있다 HTTP 특징 클라이언트 서버 구조 무상태 프로토콜 (stateless) , 비연결성 HTTP 메시지 단순함 , 확장 가능
https://www.google.com:443/search?q=hello&hl=ko 1. DNS 서버를 조회한다 -> IP : 200.200.200.2 2. HTTPS PORT 생략 , 443 3. HTTP 요청 메시지 생성 GET /search?q=hello&hl=ko HTTP/1.1 Host:www.google.com path , query , HTTP 버전 정보 , host 정보가 들어간다 4. HTTP 패킷에 전송 데이터와 메시지를 담아 전송한다 5. HTTP 메시지를 해석한다 6. 서버에서 HTTP 응답 메시지를 만들어 보낸다 HTTP/1.1 200 OK => http 버전 / 정상 응답 Content-Type: text/html; => 응답하는 데이터 형식 charset=UTF-8 => 언어..