✌ Web Programming
- HTTP(S) Protocol 로 통신하는 Client-server development.
- web-client : Internet explorer, chrome, firefox 등 (이미 개발된 web-browser 를 사용하는게 일반적이나, 직접 만들어서 사용하는 경우도 존재함)
- Web-browser
- Linux “curl” command
- Telnet
- 직접 만든 Client
🙊 HTTP Protocol
- Web-server 와 Web-client 사이의 데이터를 주고받기 위해 사용하는 통신 방식 (규약) 으로, TCP/IP Protocol 위에서 동작. 즉, server와 client 는 TCP/IP 동작에 필수적인 IP 주소를 가져야 함.
- ex) Request message (No body)
GET /book/shakespeare HTTP/1.1
Host: www.example.com:8080
- Start Line (Request line or State line)
Request Method + Request URL + Protocol version
- Header
Name : Value 표현, 여러 줄도 가능.
GET <http://www.example.com:8080/book/shakespeare> HTTP/1.1
// URL에 Host를 표시하면 Host header 생략 가능
ex) State message
HTTP/1.1 200 OK
Content-Type: application/xhtml+xml; charset=utf-8
<html>
...
<html>
- State Line
Protocol version + State code + State text
- Header
이 메시지는 바디를 갖고 있기 때문에 헤더와 바디를 빈 줄로 구분하고 있음.
- URI vs URL
URI (Uniform Resource Indentifier) 의 약자로 URL (Uniform Resource Locator) + URN (Uniform Resource Name) 인 넓은 의미의 표현이지만 Web programming 에서는 동일한 의미로 사용됨.
🙅 HTTP 처리 방식
- HTTP method 를 통해서 client가 원하는 처리 방식을 server에 알려줌.
- HTTP Method
| Method name | Meaning | CRUD mapping |
| GET | 리소스 취득 | Read(조회) |
| POST | 리소스 생성, 리소스 데이터 추가 | Create(생성) |
| PUT | 리소스 변경 | Update(변경) |
| DELETE | 리소스 삭제 | Delete(삭제) |
| HEAD | 리소스의 헤더(메타데이터) 취득 | |
| OPTIONS | 리소스가 서포트하는 메소드 취득 | |
| TRACE | 루프백 시험에 사용 | |
| CONNECT | 프록시 동작의 터널 접속으로 변경 |
- 주요 HTTP Method
1. GET
URL 정보를 가져오는 method로, Web browser를 이용하여 서버로부터 웹 페이지, 이미지, 동영상 등을 가져오려고 할 때 사용됨.
URL 부분의 ? 뒤에 이름=값 쌍으로 이어붙여 보냄.
GET <http://docs.djangoproject.com/search/?q=forms&release=1> HTTP/1.1
→ Parameter를 보내는 방식의 차이로 인해 많은 양의 데이터를 보내기 어려움. (URL의 길이 제한)
→ 전달되는 사용자의 데이터가 웹 브라우저 주소창에 노출된다는 단점으로 인한 보안 이슈.
2.POST
블로그에 글을 등록하는 경우가 이에 해당됨. (리소스 생성)
URL에 포함시켰던 parameter들을 요청 메시지의 바디에 넣음
POST <http://docs.djangoproject.com/search/> HTTP/1.1
Content-Type: application/x-www-form-urlencoded
q=forms&release=1
→ 폼을 사용하거나 추가적인 Parameter를 서버로 보내는 경우 이 방식을 더 사용함.
3. PUT
블로그에서 글을 업로드한 작성자를 변경하거나 글의 내용을 업데이트하는 경우
4. DELETE
리소스 삭제, Body를 반환하지 않음.
- State code (상태 코드)
Server 에서의 처리 결과를 알 수 있는 코드.
세 자리 숫자로 되어 있는데, 첫 번째 숫자는 HTTP 응답의 종류를 구분하는데 사용하고, 나머지 두 개의 숫자는 세부적인 응답 내용의 구분을 위한 번호.
- State code 분류
| Method name | Meaning | CRUD mapping |
| 1xx | informational (정보 제공) | 임시적인 응답으로, 현재 클라이언트의 요청까지 처리되었으니 계속 진행하라는 의미. |
| 2xx | Success(성공) | 클라이언트의 요청이 서버에서 성공적으로 처리되었다는 의미. |
| 3xx | Redirection | 완전한 처리를 위해서 추가적인 동작을 필요로 하는 경우. 주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니 그 주소로 다시 시도해보라는 의미. |
| 4xx | Client Error | 없는 페이지를 요청하는 것처럼 클라이언트의 요청 메시지가 잘못된 경우 |
| 5xx | Server Error | 서버 측 사정에 의해서 메시지 처리에 문제가 발생한 경우. 서버의 부하, DB 처리 과정 오류, 서버에서 익셉션이 발생하는 경우가 이에 해당됨. |
- 자주 사용되는 상태 코드
| State code | State Text | 응답 문구 | 서버 측면에서의 의미 |
| 2xx | Success | 성공 | 클라이언트가 요청한 동작을 수신하여 이해했고, 승낙했으며 성공적으로 처리함. |
| 200 | OK | 성공 | 서버가 요청을 성공적으로 처리했다. |
| 201 | Created | 생성됨 | 요청이 처리되어서 새로운 리소스가 생성되었음. 응답 헤더 Location에 새로운 리소스의 절대 URL 기록. |
| 202 | Accpeted | 허용됨 | 요청은 접수했지만 처리가 완료되지 않음. 클라이언트는 응답 헤더의 Location, Retry-After 를 참고하여 다시 요청을 보냄. |
| 3xx | Redirection | 리다이렉션 | 클라이언트는 요청을 마치기 위해 추가적인 동작을 취해야 한다. |
| 301 | Moved Permanently | 영구 이동 | 지정한 리소스가 새로운 URL로 이동. 이동할 곳의 새로운 URL은 응답 헤더 Location에 기록. |
| 303 | See Other | 다른 위치 보기 | 다른 위치로 요청하라. 요청에 대한 처리 결과를 응답 헤더 Location에 표시된 URI에서 GET으로 취득할 수 있음. 브라우저의 폼 요청을 POST로 처리하고 그 결과 화면으로 리다이렉트시킬 때, 자주 사용하는 응답 코드. |
| 307 | Temporary Redirect | 임시 리다이렉션 | 임시로 리다이렉션 요청이 필요하다. |
| 4xx | Client Error | 클라이언트 에러 | 클라이언트의 요청에 오류가 있다. |
| 400 | Bad Request | 잘못된 요청 | 요청의 구문이 잘못되었다. |
| 401 | Unauthorized | 권한 없음 | 지정한 리소스에 대한 엑세스 권한이 없다. |
| 403 | Forbidden | 금지됨 | 지정한 리소스에 대한 액세스가 금지되었다. |
| 404 | Not Found | 찾을 수 없음 | 지정한 리소스를 찾을 수 없다. |
| 5xx | Server Error | 서버 에러 | 클라이언트의 요청은 유효한데, 서버가 처리에 실패했다. |
| 500 | Internal Server Error | 내부 서버 오류 | 서버쪽에서 에러 발생. |
| 502 | Bad Gateway | 불량 게이트웨이 | 게이트웨이 또는 프록시 역할을 하는 서버가 그 뒷단의 서버로부터 잘못된 응답을 받았다. |
| 503 | Service Unavailable | 서비스 제공불가 | 현재 서버에서 서비스를 제공할 수 없다. |
👍 URL 설계
- 웹 서버 로직 설계의 첫걸음으로, 사용자 또는 웹 클라이언트에게 웹 서버가 가지고 있는 기능을 명시해주는 중요한 단계.
- URL 스킴 : URL에 사용된 프로토콜
- 호스트명 : 웹 서버의 호스트명으로, 도메인명 또는 IP 주소로 표현.
- 포트번호 : 웹 서버 내의 서비스 포트번호로 생략 시에는 Default 포트번호로 http는 80, https는 443 사용됨.
- 경로 : 파일이나 애플리케이션 경로
- 쿼리스트링 : 질의 문자열로, &로 구분된 이름=값 쌍 형식으로 표현됨.
- 프라그먼트 : 문서 내의 앵커 등 조각을 지정
👀 URL을 바라보는 측면
Web-Client 에서 호출한다는 시점으로 보면 웹 서버에 존재하는 애플리케이션에 대한 API (Application Programming Interface) 라고 할 수 있음. API의 명명 규칙을 정하는 방법은 두 가지로 분류 가능함.
1. RPC (Remote Procedure Call)
- 클라이언트가 네트워크상에서 원격에 있는 서버가 제공하는 API 함수를 호출하는 방식으로, 두 설계를 동일하게 고려하여 URL의 경로를 API의 함수명으로, 쿼리 파라미터를 함수의 인자로 간주하여 인식.
- 자바의 일반적인 함수나 메소드명이 동사인 것처럼 URL 경로의 대부분이 동사가 됨.
- 그러나, REST 방식이 나오면서 점차 사용빈도가 줄어들고 있음.
<http://blog.example.com/search?q=test&debug=true>
2. REST (Representational State Transfer)
- 서버에 존재하는 요소들을 모두 리소스라고 정의하고, URL을 통해 웹 서버의 특정 리소스를 표현한다는 개념.
- 이 리소스는 시간에 따라 상태가 변할 수 있기 때문에, 클라이언트와 서버 간의 데이터의 교환을 리소스 상태의 교환으로 간주하고 있음. 여기서 중요한 점은 리소스에 대한 조작을 GET, POST, PUT, DELETE 등의 HTTP 메소드로 구분한다는 것임.
<http://blog.example.com/search/test>
✨ 간편 URL
- REST 방식을 기반으로 간단하면서 사용자에게 친숙하게 표현하려고 생겨남.
- 쿼리스트링 없이 경로만 가진 간단한 구조의 URL.
😂 파이썬 URL
- 간편 URL 방식을 도입하였고, URL을 정의하기 위해 정규표현식을 추가적으로 사용 가능함.
urlpatterns = [
path('articles/2023/', views.special_case_2003),
re_path(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive),
re_path(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})$', views_month_archive),
re_path(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/(?P<slug>[w-]+)/$', views_article_detail),
]
😒 Web Application Server (SW 측면에서의 서버 프로그램)
| 구분 | 역할 | 프로그램 명 |
| 웹 서버 | 웹 클라이언트의 요청을 받아서 요청을 처리하고, 그 결과를 웹 클라이언트에 응답한다. 주로 정적 페이지인 HTML, 이미지, CSS, Javascript 파일을 웹 클라이언트에 제공할 때 웹 서버를 사용함. 만일 동적 페이지 처리가 필요하다면 웹 애플리케이션 서버에 처리를 넘김. | Apache httpd, Nginx, lighttpd, IIS 등 |
| 웹 애플리케이션 서버 | 웹 서버로부터 동적 페이지 요청을 받아서 요청을 처리하고, 그 결과를 웹 서버로 반환함. 주로 동적 페이지 생성을 위한 프로그램 실행과 데이터베이스 연동 기능을 처리함. | Apache Tomcat, JBoss, WebLogic, WebSphere, Jetty, Jeus 등 |
- 정적 페이지 vs 동적 페이지
1. 정적 페이지
- 누가, 언제 요구하더라도 항상 같은 내용을 표시하는 웹 페이지
- 제공자가 사전에 준비하여 서버 측에 배치함
- 동일한 리소스의 요청에 대해서 항상 동일한 내용의 페이지 반환
- HTML, Javascript, CSS, Image 만으로 이루어진 페이지
2. 동적 페이지
- 동일한 리소스의 요청이라도 누가, 언제, 어떻게 요구했는지에 따라 각각 다른 내용이 반환되는 페이지
- 예를 들어, 현재 시각을 보여주는 페이지나 온라인 쇼핑 사이트에서 사용자마자 다른 카트 내용을 보여주는 페이지
💁 CGI (Common Gateway Interface) 방식
- 별도의 프로그램과 웹 서버 사이의 정보를 주고받는 규칙
- 웹 서버와 독립적인 프로그램(프로세스) 사이의 정보를 주고받는 규격으로, 이 규격만 준수하면 어떤 언어를 사용해도 CGI Program 개발 가능
- 단점
각각의 클라이언트 요청에 대해서 독립적인 별도의 프로세스가 생성되어 요청이 많아질수록 프로세스가 많아지고, 비례하여 메모리 요구량이 커져 시스템에 많은 부하를 준다.
🙊 CGI 방식 대안 기술
- 별도의 애플리케이션을 스크립트 언어로 작성하고, 스크립트 처리하는 엔진을 웹 서버에 내장시켜 별도의 프로세스를 실행시키는 오버헤드를 줄이는 방식.
- 애플리케이션을 처리하는 프로세스를 미리 데몬으로 실행시켜놓은 후, 웹 서버의 요청을 데몬에서 처리하는 방식.
→ 데몬 방식에서 객체 지향 기술이 반영되어 애플리케이션 서버 방식으로 발전됨.
😆 애플리케이션 서버 방식
웹 애플리케이션 서버 방식을 통해서 간접적으로 웹 애플리케이션 프로그램을 실행
웹 서버와 웹 애플리케이션 서버를 분리하여 서로의 역할을 구분하여 사용하는 것이 좋음
→ 정적 페이지를 처리하는 경우에 비해 동적 페이지를 처리하는 경우가 많은 메모리를 소비하기 때문.
→ 정적 페이지에 특화된 웹 서버는 정적 페이지만 처리하고, 동적 페이지에 특화된 웹 애플리케이션 서버는 동적 페이지만 처리할 수 있도록 분리하는 것이 더 많은 요청을 처리할 수 있음.
- 캐시 기능, 프록시 기능 등의 추가적인 기능을 제공
😆Web Application Server Box (HW 측면에서의 프로그램)
- 서비스 운용 관리 측면에서 하나의 HW 박스에 구성하는 것이 좀 더 간편한 방식
- HW 박스를 분리하여 구성해서 메모리 효율을 높임
→ 각각 페이지를 처리하는 메모리 사이즈 비율을 조절할 수 있기 때문임.
'Back-end > Django' 카테고리의 다른 글
| Django 기본 요소 (URL과 View, Model) (1) | 2024.12.29 |
|---|---|
| Django 개발 준비 (1) | 2024.12.26 |
| Django CSS (3) | 2024.10.22 |
| Django HTML (3) | 2024.10.09 |