'Technical Note'에 해당되는 글 134건

Technical Note/apache & tomcat

아파치(Apache) 웹서버 httpd.conf 파일에 다음을 추가해 주시면 됩니다. ^^


vi httpd.conf

............................................


# 에러 로그 파일 설정 - 100 메가(MB) 초과시 새로운 로그 파일 생성(cronolog 대체 추천)

# ErrorLog "logs/error_log"

ErrorLog "|/usr/local/apache/bin/rotatelogs /usr/local/apache/logs/error_log_'20'%y-%m-%d 100M"


Technical Note/apache & tomcat

100 : Continue 

101 : Switching protocols 
200 : OK, 에러없이 전송 성공 
201 : Created, POST 명령 실행 및 성공 
202 : Accepted, 서버가 클라이언트 명령을 받음 
203 : Non-authoritative information, 서버가 클라이언트 요구 중 일부 만 전송 
204 : No content, 클라언트 요구을 처리했으나 전송할 데이터가 없음 
205 : Reset content 
206 : Partial content 
300 : Multiple choices, 최근에 옮겨진 데이터를 요청 
301 : Moved permanently, 요구한 데이터를 변경된 임시 URL에서 찾았음 
302 : Moved temporarily, 요구한 데이터가 변경된 URL에 있음을 명시 
303 : See other, 요구한 데이터를 변경하지 않았기 때문에 문제가 있음 
304 : Not modified 
305 : Use proxy 
400 : Bad request, 클라이언트의 잘못된 요청으로 처리할 수 없음 
401 : Unauthorized, 클라이언트의 인증 실패 
402 : Payment required, 예약됨 
403 : Forbidden, 접근이 거부된 문서를 요청함 
404 : Not found, 문서를 찾을 수 없음 
405 : Method not allowed, 리소스를 허용안함 
406 : Not acceptable, 허용할 수 없음 
407 : Proxy authentication required, 프록시 인증 필요 
408 : Request timeout, 요청시간이 지남 
409 : Conflict 
410 : Gone, 영구적으로 사용할 수 없음 
411 : Length required 
412 : Precondition failed, 전체조건 실패 
413 : Request entity too large, 
414 : Request-URI too long, URL이 너무 김 
415 : Unsupported media type 
500 : Internal server error, 내부서버 오류(잘못된 스크립트 실행시) 
501 : Not implemented, 클라이언트에서 서버가 수행할 수 없는 행동을 요구함 
502 : Bad gateway, 서버의 과부하 상태 
503 : Service unavailable, 외부 서비스가 죽었거나 현재 멈춤 상태 
504 : Gateway timeout 

505 : HTTP version not supported 


Technical Note/apache & tomcat
Prefork 방식의 아파치 서버일 경우 한명의 client 접속시 일반적으로 5~10MB 정도의 메모리를 사용하게 된다.
-> ps aux 명령어 결과에서 RSS 크기를 참조한다. 아래 예시를 보면

# /usr/ucb/ps aux | grep apac
root 8688 0.0 0.1 5280 3936 ? S 1월 21 0:55 /home/apac
nobody 17125 0.0 0.1 5280 2536 ? S 14:02:27 0:00 /home/apac
nobody 17126 0.0 0.1 5280 2536 ? S 14:02:28 0:00 /home/apac
nobody 17127 0.0 0.1 5280 2536 ? S 14:02:28 0:00 /home/apac
nobody 17128 0.0 0.1 5280 2536 ? S 14:02:29 0:00 /home/apac
nobody 17129 0.0 0.1 5280 2536 ? S 14:02:29 0:00 /home/apac
nobody 17130 0.0 0.1 5280 2536 ? S 14:02:29 0:00 /home/apac
nobody 17131 0.0 0.1 5280 2536 ? S 14:02:29 0:00 /home/apac
root 20143 0.0 0.1 1776 1424 pts/2 S 17:55:55 0:00 grep apac

메모리가 8GB 이고, 기본적으로 OS에서 1GB 사용, DB 등 다른 S/W에서 1GB 사용하여 6GB가 여분이고, 편의상 client당 10MB 사용한다면
6GB*1024/10MB = 614.4 로 약 600여명이 동시접속 가능하게 된다.

물론, 이는 메모리만 산정할 경우를 계산한 것이다.


네트워크 밴드위스의 경우,
웹서버는 이미지 외에 크게 전송할 콘텐츠가 아니므로 보통 300KB/sec
정도면 훌륭합니다. 그러나 실제로 클라이언트 환경에 좌우되기 때문에
이 속도까지 나오지 않고 보통 10 ~ 300KB/sec 정도입니다.

여기에서는 편의상 작은 50KB/sec 으로 잡는다면
50KB/sec = 50 * 8 KBits/sec = 400Kb/sec 입니다.

10MBPS => 10Mb/sec = 10*1024Kb/sec / 400Kb/sec => 26 Clients


Technical Note/apache & tomcat

HTTP는 아시다 시피 connection less 방식으로 연결을 매번 끊고 새로 생성하는 구조입니다

이는  network 비용측면에서 많은 비용을 소비하는 구조입니다. (최초 연결하기 위한 준비과정을 의미함)
그래서 HTTP 1.1 부터는 keep-alive라는 기능을 지원합니다

keep-alive란 
keep-alive란 연결된  socket에 IN/OUT 의 access가 마지막으로 종료된 시점부터 정의된 시간까지  access가 없더라도 대기 하는 구조입니다 즉, 정의된 시간내에서 access 가 이루어진다면 계쏙 연결된 상태를 유지할 수 있다는 것 이죠.

 HTTP 에서 Keep-alive란
 HTTP는 앞서 설명드린 것과 같이 connection less방식이라 매번 socket 을 열어야 하고 이는 비용적인 측면에서 비효율적인 구조입니다. 해서 keep alive time out내에 client에서 request를 재 요청하면 socket를 새로 여는 것이 아니라 이미 열려 있는 socket에 전송하는 구조가 됩니다.


http://softark.co.kr/entry/HTTP-11-Keep-Alive-%EA%B8%B0%EB%8A%A5%EC%97%90-%EB%8C%80%ED%95%B4

Technical Note/apache & tomcat

301은 영구적인, 302는 일시적인 redirect를 뜻한다.


 

이런 경우 301이 적당합니다.

  1. 페이지가 삭제되었거나, 이동되었습니다.
  2. 도메인 주소를 바꾸어서 이전 도메인의 트래픽을 가져오고 싶습니다.
  3. www가 빠진 도메인 주소에서 www를 붙인 주소로 트래픽을 모으고 싶습니다.
  4. 동일한 내용의 페이지를 다른 도메인 이름으로 제공하고 싶습니다.
  5. 읽기 쉬운 URL을 만들고 싶습니다.
    - www.example.com/index.php?aaa=bbb&ccc=123&ddd=47dh
    -> www.example.com/bbb/123/47dh


이런 경우에만 302를 사용하세요.

  1. 쇼핑몰의 이벤트 페이지처럼 내용은 자주 바뀌지만 주소는 고정하고 싶을 때
  2. 메인 페이지에 걸어 트래픽을 다른 페이지에 나누어주고 싶을때
  3. 기술적인 문제? 등으로 잠시동안 해당 주소를 사용할 때

302 Hijack? 

302 redirection으로 A사이트로 검색엔진에 인덱스 된 페이지가 B사이트로 납치? 됩니다. 이것은 악의적인 사용자가 고의적으로 만들어 낸다거나, 납치당하는 사이트 입장에서 할 수 있는 것이 아닌것으로 알려져 있습니다. 기술적인 것으로는 A의 사이트에서 B사이트로 redirection을 걸면, 검색 로봇은 A사이트를 통해서도, B사이트를 통해서도 동일한 내용을 가진 페이지를 발견할 수 있게 됩니다. 크롤된 A, B의 내용이 인덱스 되는 과정에서 발생할 수 있는 문제라는 것이 널리 알려진 이유입니다만 정확한 것은 구글 기술자만이 알겠죠;;


참고

http://news.stepforth.com/blog/2008/01/redirects-permanent-301-vs-temporary.php

http://clsc.net/research/google-302-page-hijack.htm


1 ··· 17 18 19 20 21 22 23 ··· 27
블로그 이미지

zzikjh